Related
I ran into an issue where my Android app cannot make outgoing connections using the TcpClient class (question located here). While debugging and conducting further research, I found that my Android device (API level 22) is receiving a subnet mask of 0.0.0.0 when it connects to my WiFi network. My DHCP server is configured to use 255.255.255.0, so I believe this discrepancy could be the root of my other problem. This is my code:
//Connect to the WiFi network
int id = WiFiManager.AddNetwork(new WifiConfiguration()
{
Ssid = $"\"{ssid}\"",
PreSharedKey = $"\"{password}\""
});
WiFiManager.EnableNetwork(id, true);
WiFiManager.Reconnect();
//Retrieve subnet mask (for debugging)
int subnet_mask = WiFiManager.DhcpInfo.Netmask;
subnet_mask returns 0, and the formatted version of the DhcpInfo class shows:
{ipaddr 10.0.0.15 gateway 10.0.0.0 netmask 0.0.0.0 dns1 10.0.0.0 dns2 0.0.0.0 DHCP server
10.0.0.0 lease 43200 seconds}
With this being the situation, is there any way I can manually change the subnet mask (or "netmask") within the Android API? I have tried using a static IP configuration as shown here, but use of those settings was deprecated in API level 17. I have also tried setting the DhcpInfo.Netmask property manually, but it takes an int. I calculated one based on this answer, but it was too large and became a uint. Lastly, I looked through a variety of classes, including Android.Net.Wifi.WifiManager, to see if there was a way to change the netmask. I didn't find anything, but I might have just been looking in the wrong places.
Any help is greatly appreciated!
Update:
For security reasons, it seems like this is not possible with the standard Android API. However, is the Android NDK able to change the subnet mask? I understand it provides lower-level access to the device, and I do not need to put this app on the app store (it is for my use only).
For security reasons, Android OS may not allow you to do this.
I know as a user I would not want an app to change my network configuration.
It seems this may have been able to be done in the past: https://stackoverflow.com/a/7142316/2913599
but that API is obsolete/deprecated in API level 17: https://developer.android.com/reference/android/provider/Settings.System.html#WIFI_STATIC_DNS1
Docs say to use WifiManager instead, but that API does not allow changing the ip, dns, gateway, again for security reasons.
If you need to get these settings changed, perhaps you can provide an instruction page for the user so they can change them themselves.
Morning folks,
I have tried to modify VPN sample (ToyVPN) to work as a simple firewall to block some outgoing traffic. I decided to do it the following way:
Create a VPN Connection for some IPs only
Do nothing in the VPN handling code :)
Which seems easier than assessing the packets and act according to their contents.
This seems to work well for Android 4.3 but on 4.4 I receive an error:
...
09-03 06:02:11.340 1806-1897/com.example.android.toyvpn E/ToyVpnService﹕ Got java.lang.IllegalStateException: command '43 interface fwmark rule add tun0' failed with '400 43 Failed to add fwmark rule (No such device)'command '43 interface fwmark rule add tun0' failed with '400 43 Failed to add fwmark rule (No such device)'
...
Here is my VpnService Builder code:
Builder builder = new Builder();
builder.setMtu(30000);
builder.addAddress("10.0.0.1",24);
builder.addRoute("212.77.100.101",32); // this is a sample IP I use for tests
mInterface = builder.setSession(mServerAddress)
.setConfigureIntent(mConfigureIntent)
.establish();
Run code I have does nothing:
while (true){
Thread.sleep(1000);
Log.e(TAG,"Running");
}
In result I get what I want - traffic to my manually entered IP is routed to a /dev/null kind of interface :)
I do believe my issue with KitKat is related to some bugs/issues in Android 4.4 (e.g. https://code.google.com/p/android/issues/detail?id=63349 but there a more VPN related ones).
But I know that what I try to achieve is doable - https://play.google.com/store/apps/details?id=com.netspark.firewall is a proof that works well on my 4.4 phone. And its done via VpnService as the same VPN pop-up cames when using this app.
Could you please help me understand what am I doing wrong and how to get VpnService operational on 4.4 ... not really to do VPN-ing but rather some simple firewall-ing.
This all applies to non rooted devices.
PS. Is there some limitation on the number of IPs (IP subnets) I can add to VpnService this way?
I hava do this issue,first you must understand android VpnService give you ParcelFileDescriptor,in this you can get ip packet,it can be cast to Linux iphdr * pointer ,so you get the packet srcIP and dstIP dstPort,you can choose drop or traffic this packet.if you have another issue you can build tcp or udp packet from ip packet,at this level you can get host ip and website .
I have been doing some low-level hacking on Android.
I'm trying to enable wifi i.e. establish Internet Connectivity through terminal (adb shell). I have written a C program to achieve this by hacking into android's bionic library and libnetutils library to get things working.
Everything works fine. I'm able to acquire an IP address via dhcp request. The problem is that whenever I try to open any site for ex. google.com via browser, it does not opens. But when I enter the IP address of the site "74.125.228.66" (google.com), the page gets loaded.
I have tried several options, like modifying the dns entries in file "resolv.conf" (present in /system/etc) and in file "20-dns.conf" (in /system/etc/dhcpcd/dhcpcd-hooks).
I also tried using "setprop" call to set dns values manually for "dhcp.eth0.dns*" and "dhcp.wlan0.dns*".
But nothing seems to work. There's also an interesting behavior I noticed. If I turn on wifi manually from "settings" menu and then turn it off and then run my program, I don't face this issue anymore. Looks like it uses some settings that I could not figure out.
My guess is that this is DNS issue, but it may be something else. Let me know if anyone has faced this issue before.
Here's is what I do to enable wifi:
Enable wpa_supplicant daemon using set_prop().
Send a dhcp request to acquire IP (code from dhcpclient.c in libnetutils).
Enable dhcpcd daemon using set_prop(). (Even without this, everything works. I ran this so that IP lease gets renewed automatically. ( Although I'm not sure about this, if dhcpcd daemon would take care of lease renewal or not) ).
In order to enable WIFI on Android via command line through a C program, you'll need to do the following:
1) Enable wpa_supplicant daemon. (Make sure you have the wpa_supplicant.conf file at /data/misc/wifi with AP (access point) information in it.). wpa_supplicant internally takes care of loading the driver and then establishes connectivity to the specified networks in its configuration file based on availability and strength.
2) Issue a dhcp request. ( To fetch IP, lease, dns1, dns2 etc.)
3) Start dhcpcd daemon. (For Lease renewal)
4) Set net.dns* properties. (Without this, DNS service would not work for any application)
In order to enable daemons (wpa_supplicant and dhcpcd) and set net.dns* properties , you'll need to use Android property system (property_set() and property_get() functions). To learn more about Android Property System, follow this link:
http://rxwen.blogspot.com/2010/01/android-property-system.html
In order to use above 2 functions, you'll need to hack into bionic and core libcutils library.
Location:
/bionic/libc/bionic/system_properties.c
/system/core/libcutils/properties.c
For issuing dhcp request, you need to hack some of the implementation of libnetutils
Location:
/system/core/libnetutils/*
Disabling Wifi:
1) Unload the driver manually.
2) Stop wpa_supplicant daemon.
3) Stop dhcpcd daemon.
4) Unset net.dns* properties.
In this case, driver needs to be unloaded manually unlike loading. If this step is not done, then any of the existing connections will not be torn apart even after 2, 3, and 4. To manually unload the driver, you need to issue "DRIVER STOP" request to wpa_supplicant which will take care of interacting with kernel to unload the driver.
In order to communicate with wpa_supplicant, you'll need to hack into wpa_cli implementation to see how it works. It basically uses UNIX Domain Sockets to interact with the supplicant. You basically need to have a look at wpa_ctrl.c and wpa_cli.c
To learn more about wpa_supplicant, wpa_cli, follow below link:
http://hostap.epitest.fi/wpa_supplicant/devel/
All above that I explained to you is done in Android at HAL layer.
Location:
/hardware/libhardware_legacy/wifi/wifi.c
So, basically whenever you toggle wifi switch from settings menu, control passes from wifi_app code to wifi_frameworks layer (WifiManager and WifiServices) which passes control to wifi.c (HAL layer) through JNI implementation (WifiNative).
A good starting point would be to look at wifi.c if you want to know things that are done at low level to enable wifi.
PS - All above is what I learned after several attempts trying to figure out stuff on my own. There are no documents or blogs (atleast I didn't find any!) that would specify what needs to be done and order of events that should be followed to enable/disable WIFI. So, it may be possible you might find a better way of doing things. This worked for me, something else might work for you!
I want to be able to discover Android devices on my network and possibly retrieve some device information about them. This is very easy with Apple devices since they run Bonjour services. However, I can't seem to find any similar service running on Android.
This must work without modifying the Android device, installing some service, or opening some port. It's meant to work with vanilla Android devices in the way that Bonjour helps you find vanilla Apple devices. Even being able to just verify that the device is running Android would be sufficient.
Chosen Answer: Although it's not the top rated answer (yet), please take a look at the response by Luis. As he mentions, you can use a DNS lookup (using your local DNS server) to discover Android devices. I have found this to have a 100% success rate, as Android forces devices to use a hostname of android-_____. This is apparently difficult to change on the phone, even if it is rooted. So I think this is a pretty accurate method. Thanks, Luis!
Example:
$ nslookup 192.168.1.104 192.168.1.1
Server: 192.168.1.1
Address: 192.168.1.1#53
104.1.168.192.in-addr.arpa name = android-711c129e251f14cf.\001.
Sample Code: If you wanted to implement this in Java (e.g., to run on Android), you can't easily use getHostName() because it uses the external DNS servers. You want to use the local DNS server on your router, for example. Luis mentions below that you could modify the DNS servers of the Wifi connection, but that could possibly break other things. Instead, I've found the dnsjava library to be extremely helpful to send targeted DNS requests. Here is some sample code using the library:
String ipAddress = "104.1.168.192";
String dnsblDomain = "in-addr.arpa";
Record[] records;
Lookup lookup = new Lookup(ipAddress + "." + dnsblDomain, Type.PTR);
SimpleResolver resolver = new SimpleResolver();
resolver.setAddress(InetAddress.getByName("192.168.1.1"));
lookup.setResolver(resolver);
records = lookup.run();
if(lookup.getResult() == Lookup.SUCCESSFUL) {
for (int i = 0; i < records.length; i++) {
if(records[i] instanceof PTRRecord) {
PTRRecord ptr = (PTRRecord) records[i];
System.out.println("DNS Record: " + records[0].rdataToString());
}
}
} else {
System.out.println("Failed lookup");
}
} catch(Exception e) {
System.out.println("Exception: " + e);
}
This gives me the output:
DNS Record: android-711c129e251f14cf.\001.
Bingo.
There is an very simple approach that gave me positive results in few different devices.
When a device connects to your router it receives an IP (i.e. DHCP) and registers a name in DNS. The name that is registered seems to be always in the form android_nnnnnnnn.
Of course, you can name any computer with the same approach and trick the check, resulting in false positives ...
Also, I can't ensure that all device suppliers are following the same approach, but I've found it to work correctly in a few devices from different brands (including different SDK levels) that I've tested.
--EDITED--
How to do it
It depends on where you would be running the code to discover the Android devices. Assuming that you would be running the code in an Android device:
First discover devices responding to ping in your network. You can use the code in my answer to this post: execComd() to run a ping command.
Get the name of responding devices using the code:
InetAddress inetAddress = InetAddress.getByName(string_with_ip_addr);
String name = inetAddress.getCanonicalHostName();
--EDIT 2--
Proof of concept
The method below is just a proof of concept for what I've wrote above.
I'm using isReachable() method to generate the ICMP request, which is said to only work with rooted devices in many posts, which is the case for the device used for testing it. However, I didn't give root permissions for the application running this code, so I believe it couldn't set the SIUD bit, which is the reason why some claim that this method fails. I would like to do it here from the perspective of someone testing it on a non-rooted device.
To call use:
ArrayList<String> hosts = scanSubNet("192.168.1.");
It returns in hosts, a list of names for devices responding to ping request.
private ArrayList<String> scanSubNet(String subnet){
ArrayList<String> hosts = new ArrayList<String>();
InetAddress inetAddress = null;
for(int i=1; i<10; i++){
Log.d(TAG, "Trying: " + subnet + String.valueOf(i));
try {
inetAddress = InetAddress.getByName(subnet + String.valueOf(i));
if(inetAddress.isReachable(1000)){
hosts.add(inetAddress.getHostName());
Log.d(TAG, inetAddress.getHostName());
}
} catch (UnknownHostException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
}
return hosts;
}
Regards.
Android is not going to be as easy as iOS. There is no Bonjour equivalent.
Android 4.0, Ice Cream Sandwich, introduced Wi-Fi Direct Peer to Peer networking. At first I hoped it might be able to be scanned in the the way your thinking, but it helps Android devices communicate without an access point, so they're not really "on your network". Besides, ICS runs on only a fraction of Android devices.
Rather than an active netscan approach, you're left with a passive monitoring approach. If your network is secure, sniffing the encrypted packet is possible, but inconvenient. You'll have to
put your network interface into monitor mode
capture the 4-way handshake
decrypt it using the network's pre-shared key
this will give you the key you need to decrypt traffic
If you want to see this in action, Wireshark supports WPA decryption.
Once you're able to view the Wi-Fi traffic, you will notice Android devices tend to communicate with certain Google servers and their HTTP connections have User Agent strings that can be identified.
This is the basis for a workable passive solution.
Tenable Network Security offer products that seem to take this type of approach.
Another Idea
#Michelle Cannon mentioned Libelium's Meshlium Xtreme whose approach will not get you all the way there (not without good up to date MAC address range tables). But it could be part of reaching a lesser goal.
You can:
Detect all wireless devices
Eliminate Apple devices using the MAC's Organizationally Unique Identifier (OUI)
Tell it's a mobile device by by monitoring signal strength to determine it's moving (and mobile devices will tend to show up and go away)
You may be able to use the MAC OUI as a hint it's Android
You may be able to use the MAC OUI as a hint it's not Android (but a laptop or wireless card, etc.).
This may be workable if your willing to detect devices that are probably Android.
DHCP Fingerprinting
#Michelle Cannon suggested DHCP fingerprinting. I wasn't sure at first but I have to thank him for suggesting what's looking like the best bet for simple passive scanning. As a cautionary tail, I'd like to explain why I was late to the party.
There are things we know, thinks we don't know, and things we think we know but are wrong.
In a lot of ways, it's good that Android uses the Linux kernel. But it's not good if you want to discover Android devices on your network. Android's TCP/IP stack is Linux's therefor Android devices will look like Linux devices or so I thought at first. But then I realized Linux has a lot of build configuration parameters so there could be something distinctive about Android when seen on a network, but what?
DHCP fingerprinting uses a the exact DHCP options requested by the device plus timing. For this to work you generally need an up to date fingerprint database to match against. At first it looked like fingerbank was crowed sourcing this data, but then I noticed their files hadn't been updated for almost a year. With all the different Android device types, I don't think it's practical to keep updated fingerprints for a single project.
But then I looked at the actual DHCP signatures for Android and I noticed this:
Android 1.0: dhcpvendorcode=dhcpcd 4.0.0-beta9
Android 1.5-2.1: dhcpvendorcode=dhcpcd 4.0.1
Android 2.2: dhcpvendorcode=dhcpcd 4.0.15
Android 3.0: dhcpvendorcode=dhcpcd-5.2.10
Linux normally uses dhclient as their DHCP client, but Android is using dhcpcd. Android has a strong preference for using software licensed with the BSD style where possible and dhcpcd uses a BSD license. It would seem dhcpvendorcode could be used as a strong indicator that a mobile device is running Android.
DHCP monitoring
A client uses DHCP to get an IP address when joining a network so it's starting without an IP address. It gets around this problem by using UDP broadcasts for the initial exchange. On Wi-Fi, even with WPA, broadcast traffic is not encrypted. So you can just listen on UDP port 67 for client to server traffic and 68 for the reverse. You don't even need to put your network interface into promiscuous mode. You can easily monitor this traffic using a protocol analyzer like Wireshark.
I preferred to write code to monitor the traffic and decided to use Python. I selected pydhcplib to handle the details of DHCP. My experience with this library was not smooth. I needed to manually download and place IN.py and TYPES.py support files. And their packet to string conversion was leaving the dhcpvendorcode blank. It did parse the DHCP packets correctly, so I just wrote my own print code.
Here's code that monitors DHCP traffic from client to server:
#!/usr/bin/python
from pydhcplib.dhcp_packet import *
from pydhcplib.dhcp_network import *
from pydhcplib.dhcp_constants import *
netopt = {
'client_listen_port':"68",
'server_listen_port':"67",
'listen_address':"0.0.0.0"
}
class Server(DhcpServer):
def __init__(self, options):
DhcpServer.__init__(
self,options["listen_address"],
options["client_listen_port"],
options["server_listen_port"])
def PrintOptions(self, packet, options=['vendor_class', 'host_name', 'chaddr']):
# uncomment next line to print full details
# print packet.str()
for option in options:
# chaddr is not really and option, it's in the fixed header
if option == 'chaddr':
begin = DhcpFields[option][0]
end = begin+6
opdata = packet.packet_data[begin:end]
hex = ['0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f']
print option+':', ':'.join([(hex[i/16]+hex[i%16]) for i in opdata])
else:
opdata = packet.options_data.get(option)
if opdata:
print option+':', ''.join([chr(i) for i in opdata if i != 0])
print
def HandleDhcpDiscover(self, packet):
print "DHCP DISCOVER"
self.PrintOptions(packet)
def HandleDhcpRequest(self, packet):
print "DHCP REQUEST"
self.PrintOptions(packet)
## def HandleDhcpDecline(self, packet):
## self.PrintOptions(packet)
## def HandleDhcpRelease(self, packet):
## self.PrintOptions(packet)
## def HandleDhcpInform(self, packet):
## self.PrintOptions(packet)
server = Server(netopt)
while True :
server.GetNextDhcpPacket()
This code is based on pydhcplib's server example because it listens for client requests, like a server.
When my Nexus 7 Android 4.2 tablet connects, this interesting information is captured (redacted):
DHCP REQUEST
vendor_class: dhcpcd-5.5.6
host_name: android-5c1b97cdffffffff
chaddr: 10:bf:48:ff:ff:ff
DHCP DISCOVER
vendor_class: dhcpcd-5.5.6
host_name: android-5c1b97cdffffffff
chaddr: 10:bf:48:ff:ff:ff
The host name seems to have a fixed format and is easily parsed. If you need the IP address you can monitor the server to client traffic. Note: only the initial exchange, when an new client first shows up without an IP address, is broadcast. Future lease extensions, etc., are not broadcast.
Reverse DNS Lookup
#Luis posted a great solution that demonstrates how simpler is better. Even after seeing Android's DHCP client was setting host_name to android-5c1b97cdffffffff, I didn't think to ask the router for it's list of names using reverse DNS lookups. The router adds the host_name to it's DNS server so you can still access the device if its IP address changes.
The host_name is expected to remain listed in the DNS for the duration of the DHCP lease. You could check if the device is still present by pinging it.
One drawback to depending on host_name is there are ways this could be changed. It's easy for the device manufacturer or carrier to change the host_name (though after searching, I've been unable to find any evidence they ever have). There are apps to change host name, but they require root so that's, at most, an edge case.
Finally there's an open Android Issue 6111: Allow a hostname to be specified that currently has 629 stars. It would not be surprising to see configurable host_name in Android Settings at some point in the future, maybe soon. So if you start depending on host_name to identify Android devices, realize it could be yanked out from under you.
If you're doing live tracking, another potential problem with Reverse DNS Lookup is you have to decide how frequently to scan. (Of course this is not an issue if you're just taking a one-time snapshot.) Frequent scanning consumes network resources, infrequent leaves you with stale data. Here's how adding DHCP monitoring can help:
On startup use Reverse DNS Lookup to find devices
Ping devices to see if they are still active
Monitor DHCP traffic to detect new devices instantly
Occasionally rerun DNS Lookup to find devices you might have missed
If you need to notice devices leaving, ping devices at desired timing resolution
While it's not easy (nor 100% accurate), there are several techniques that make it possible to discover Android devices on your network.
AFAIK, Android system doesn't provide any zeroconf app/service on it's built-in system app/service stack. To enable the auto-discovery on the actual device attached to local network, you need either install some third-party zeroconf app or develop your own app/service and install it on the actual device, some API options are:
JmDNS (for Apple's bonjour protocol)
Cling (for Microsoft's UPnP protocol)
Android NSD API (introduced since Android 4.1)
I am not quite clear about your requirements, if you want something similar (i.e. auto discover and connect) on vanilla Android devices, you can probably use Wi-Fi direct which is now available on some later device running Android 4.0, however, it requires both devices support Wi-Fi Direct and only create an ad-hoc P2P connection with Wi-Fi turned off, much like a bluetooth connection with a longer range:
For Wi-Fi Direct API support, check out official guide - Connecting Devices Wirelessly.
I am looking at this an thinking
http://www.libelium.com/smartphones_iphone_android_detection
pay special note to this
Do the users need to have an specific app installed or interact somehow to be detected?
No, the scan is performed silently, Meshlium just detects the "beacon frames" originated by the Wifi and Bluetooth radios integrated in the Smartphones. Users just need to have at least one of the two wireless interfaces turned on.
Long time ago I use to use an app called stumbler on my mac to find wifi networks, I think this is similar
Other ideas
Well if I need to determine android phones on a local network how would I do it. Absent of a dns service running I only have a couple possibilities
The SSID if its being broadcast - can't tell me anything The ip address - android lets you have a lot of control over host naming so I guess you could define a specific ip range to your android devices. -not to useful.
Alternately lets say I see an unknown device on the network, if bluetooth is turned on then I am broadcasting a bluetooth device signature SDPP that I can use to deduce my device type.
If I were running a service that supported android and I wanted to discover specific android devices on my network, then I could just register the mac addresses for those devices and watch for them on the network.
Other than that you would need to run either a bonjour (dns-sd) or upnpp dameon on the device.
Updated Response
Sorry, I haven't understood the original question correctly. Only your comment made it really clear to me that you do not want to have to install anything on the target devices but you just want a way of discovering random phones in your network.
I'm not sure if this would really be possible in the way you want it. Without having any network discovery service running on Android you will not find the device in first place. Of course you can use some low-level network protocols but that would only give you an indicator that there's something but not what it is (being an Android device, a PC, a whatever else).
The most promising approach would be to check for preinstalled apps that have network functionality of some kind. E.g. Samsung devices have Kies Air (if the user enables it), Motorola are using UPnP for their Media Server and HTC has something own as well, if I remember correctly. However, there's no app that is installed on all Android devices of all vendors and carriers. So you can't rely on solely one of those but would need to check for various different services using their specific protocols and behaviors in order to get additional information about the device. And, of course, the user would have to enable the functionality in order for you to use it.
Old response
An additional alternative to yorkw's list is AllJoyn by Qualcomm. It's an open source cross-platform discovery and peer-to-peer communication framework I've used in the past myself already.
Though Qualcomm is a big sponsor of AllJoyn this does not mean that you need a Qualcomm chipset in your define. In fact AllJoyn works on any chipset including Intel and nVidia. It doesn't require rooted phones or any other modifications to the Android framework and just works "out of the box" using Wi-Fi and/or Bluetooth as pairing methods.
I am learning a lot from this topic.
there is also something called dhcp fingerprinting, apparently different devices act differently to the kind of network scans we've been discussing such as those using NMAP a linux scanner. Maps of the behavior from these probes are available on the internet.
http://www.enterasys.com/company/literature/device-profiling-sab.pdf
https://media.defcon.org/dc-19/presentations/Bilodeau/DEFCON-19-Bilodeau-FingerBank.pdf
http://community.arubanetworks.com/t5/ArubaOS-and-Mobility-Controllers/COTD-DHCP-Fingerprinting-how-to-ArubaOS-6-0-1-0-and-above/td-p/11164
http://myweb.cableone.net/xnih/
Here's a one liner that pings all of the machines on your network (assuming your network is 192.168.1.x) and does a reverse lookup on their names:
for i in {1..255}; do echo ping -t 4 192.168.1.${i} ; done | parallel -j 0 --no-notice 2> /dev/null | awk '/ttl/ { print $4 }' | sort | uniq | sed 's/://' | xargs -n 1 host
Requires GNU parallel to work. You can install that on OSX using "brew install parallel"
From this you can just look at the devices named android-c40a2b8027d663dd.home. or whatever.
You can then trying running nmap -O on a device to see what else you can figure out:
sudo nmap -O android-297e7f9fccaa5b5f.home.
But it's not really that fruitful.
I'm running a web service on my local machine that runs at localhost:54722.
I want to call the service from an app running in the Android emulator.
I read that using 10.0.2.2 in the app would access localhost, but it doesn't seem to work with the port number as well. It says HttpResponseException: Bad Request.
You can access your host machine with the IP address "10.0.2.2".
This has been designed in this way by the Android team. So your webserver can perfectly run at localhost and from your Android app you can access it via "http://10.0.2.2:<hostport>".
If your emulator must access the internet through a proxy server, you can configure a custom HTTP proxy from the emulator's Extended controls screen. With the emulator open, click More , and then click Settings and Proxy. From here, you can define your own HTTP proxy settings.
Use 10.0.2.2 for default AVD and 10.0.3.2 for Genymotion
Since 10.0.2.2 is not a secure domain for Android you have to allow non-secured domains in your network configuration for API 28+ where non-TLS connections are prevented by default.
You may use my following configurations:
Create a new file in main/res/xml/network_security_config.xml as:
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
<domain-config cleartextTrafficPermitted="true">
<domain includeSubdomains="true">localhost</domain>
<domain includeSubdomains="true">10.0.2.2</domain>
</domain-config>
</network-security-config>
And point it in AndroidManifest.xml
<application
......
......
android:networkSecurityConfig="#xml/network_security_config">
I faced the same issue on Visual Studio executing an web app on IIS Express. to fix it you need to go to your project properties then click on Debug Tab and change http://localhost:[YOUR PORT] to http://127.0.0.1:[YOUR PORT] and set the android url to http://10.0.2.2:[YOUR PORT]. it worked for me.
I'm not sure this solution will work for every Android Emulator and every Android SDK version out there but running the following did the trick for me.
adb reverse tcp:54722 tcp:54722
You'll need to have your emulator up an running and then you'll be able to hit localhost:54722 inside the running emulator device successfully.
If you are using IIS Express you may need to bind to all hostnames instead of just `localhost'. Check this fine answer:
https://stackoverflow.com/a/15809698/383761
Tell IIS Express itself to bind to all ip addresses and hostnames. In your .config file (typically %userprofile%\My
Documents\IISExpress\config\applicationhost.config, or
$(solutionDir).vs\config\applicationhost.config for Visual Studio
2015), find your site's binding element, and add
<binding protocol="http" bindingInformation="*:8080:*" />
Make sure to add it as a second binding instead of modifying the existing one or VS will just re-add a new site appended with a (1) Also, you may need to run VS as an administrator.
I solved it with the installation of "Conveyor by Keyoti" in Visual Studio Professional 2015.
Conveyor generate a REMOTE address (your IP) with a port (45455) that enable external request.
Example:
Conveyor allows you test web applications from from external tablets and phones on your network or from Android emulators (without http://10.0.2.2:<hostport>)
The steps are in the following link :
https://marketplace.visualstudio.com/items?itemName=vs-publisher-1448185.ConveyorbyKeyoti
The problem is that the Android emulator maps 10.0.2.2 to 127.0.0.1, not to localhost. So configure your web server to serveron 127.0.0.1:54722 and not localhost:54722. That should do it.
After running your local host you get http://localhost:[port number]/ here you found your port number.
Then get your IP address from Command, Open your windows command and type ipconfig
In my case, IP was 192.168.10.33 so my URL will be http://192.168.10.33:[port number]/.
In Android, the studio uses this URL as your URL. And after that set your URL and your port number in manual proxy for the emulator.
I have a webserver running on my localhost.
If I open up the emulator and want to connect to my localhost I am using 192.168.x.x. This means you should use your local lan ip address. By the way, your HttpResponseException (Bad Request) doesn't mean that the host is not reachable.
Some other errors lead to this exception.
To access localhost on Android Emulator
Add the internet permission from AndroidManifest.xml
<uses-permission android:name="android.permission.INTERNET" />
Add android:usesCleartextTraffic="true", more details here:
Run the below-mentioned command to find your system IP address:
ifconfig | grep "inet " | grep -v 127.0.0.1
Copy the IP address obtained from this step (A)
Run your backend application, which you can access at localhost or 127.0.0.1 from your sytem.
Now in android studio, you can replace the URL if you're using in code or You can use the ip address obtained from step(A) and try opening in web browser,
Like this http://192.168.0.102:8080/
Don't forget to add PORT after the IP address, in my case app was running on 8080 port so I added IP obtained in (A) with the port 8080
you need to set URL as 10.0.2.2:portNr
portNr = the given port by ASP.NET Development Server my current service is running on localhost:3229/Service.svc
so my url is 10.0.2.2:3229
i'd fixed my problem this way
i hope it helps...
"BadRequest" is an error which usually got send by the server itself, see rfc 2616
10.4.1 400 Bad Request
The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.
So you got a working connection to the server, but your request doesn't fit the expecet form. I don't know how you create the connection, what headers are included (if there are any) – but thats what you should checking for.
If you need more help about, explain what your code is about and what it uses to connect to the Server, so we have the big picture.
Here is a question with the same Problem – the answer was that the content-type wasnt set in the header.
1) Run ipconfig command in cmd
2) You will get result like this
3) Then use IPv4 Address of VMWare Network Adapter 1 followed by port number
In My Case its 8080, so instead of using localhost:8080
I am using 192.168.56.1:8080
Done.....
I would like to show you the way I access IISExpress Web APIs from my Android Emulator. I'm using Visual Studio 2015. And I call the Android Emulator from Android Studio.
All of what I need to do is adding the following line to the binding configuration in my applicationhost.config file
<binding protocol="http" bindingInformation="*:<your-port>:" />
Then I check and use the IP4 Address to access my API from Android emulator
Requirement: you must run Visual Studio as Administrator. This post gives a perfect way to do this.
For more details, please visit my post on github
Hope this helps.
For Laravel Homestead Users:
If anyone using Laravel with homestead you can access app backend using 192.168.10.10 in emulator
Still not working?
Another good solution is to use ngrok https://ngrok.com/
I am using Windows 10 as my development platform, accessing 10.0.2.2:port in my emulator is not working as expected, and the same result for other solutions in this question as well.
After several hours of digging, I found that if you add -writable-system argument to the emulator startup command, things will just work.
You have to start an emulator via command line like below:
emulator.exe -avd <emulator_name> -writable-system
Then in your emulator, you can access your API service running on host machine, using LAN IP address and binding port:
http://192.168.1.2:<port>
Hope this helps you out.
About start emulator from command line: https://developer.android.com/studio/run/emulator-commandline.
Explanation why localhost is not available from emulators for anyone who has basic access problem. For sophisticated cases read other answers.
Problem: Emulator has own local network and localhost maps itself to emulator, but NOT your host!
Solution:
Bind your server to 0.0.0.0 to make it available for emulator's network
Get external IP address of your laptop: ifconfig command for Mac
In Android (or Flutter app) use IP address of your external interface like: 192.168.1.10 instead of localhost
I had the same issue when I was trying to connect to my IIS .NET Webservice from the Android emulator.
install npm install -g iisexpress-proxy
iisexpress-proxy 53990 to 9000 to proxy IIS express port to 9000 and access port 9000 from emulator like "http://10.0.2.2:9000"
the reason seems to be by default, IIS Express doesn't allow connections from network
https://forums.asp.net/t/2125232.aspx?Bad+Request+Invalid+Hostname+when+accessing+localhost+Web+API+or+Web+App+from+across+LAN
localhost seemed to be working fine in my emulator at start and then i started getting connection refused exception
i used 127.0.2.2 from the emulator browser and it worked and when i used this in my android app in emulator it again started showing the connection refused problem.
then i did ifconfig and i used the ip 192.168.2.2 and it worked perfectly
Bad request generally means the format of the data you are sending is incorrect. May be mismatched data mapping . If you are getting bad request implies you are able to connect to the server, but the request is not being sent properly.
If anybody is still looking for this, this is how it worked for me.
You need to find the IP of your machine with respect to the device/emulator you are connected. For Emulators on of the way is by following below steps;
Go to VM Virtual box -> select connected device in the list.
Select Settings ->Network-> Find out to which network the device is attached. For me it was 'VirtualBox Host-Only Ethernet Adapter #2'.
In virtualbox go to Files->Preferences->Network->Host-Only Networks, and find out the IPv4 for the network specified in above step. (By Hovering you will get the info)
Provide this IP to access the localhost from emulator. The Port is same as you have provided while running/publishing your services.
Note #1 : Make sure you have taken care of firewalls and inbound rules.
Note #2 : Please check this IP after you restart your machine. For some reason, even If I provided "Use the following IP" The Host-Only IP got changed.
I resolved exact the problem when the service layer is using Visual Studio IIS Express. Just point to 10.0.2.2:port wont work. Instead of messing around the IIS Express as mentioned by other posts, I just put a proxy in front of the IIS Express. For example, apache or nginx. The nginx.conf will look like
# Mobile API
server {
listen 8090;
server_name default_server;
location / {
proxy_pass http://localhost:54722;
}
}
Then the android needs to points to my IP address as 192.168.x.x:8090
if you are using some 3rd party package like node express or angular-cli you will need to find the IP of your machine, and attach your host to that IP within the server startup config (instead of localhost). Then launch it from the emulator using the IP. For example, I had to use: ng serve -H 10.149.212.104 to use the angular-cli. Then from the emulator I used: http://10.149.212.104:4200
If you are working with Asp.Net Web API, in .vs/config folder inside your project, modify these lines as per you port setting. Let suppose you use port 1234 and physicalPath to the project folder set by IIS is "D:\My Projects\YourSiteName", then
<site name="YourSiteName" id="1">
<application path="/" applicationPool="Clr4IntegratedAppPool">
<virtualDirectory path="/" physicalPath="D:\My Projects\YourSiteName" />
</application>
<bindings>
<binding protocol="http" bindingInformation="*:1234:*" />
</bindings>
</site>
In android studio, access your api with "http://10.0.2.2:1234" ...