Through WifiManager, my Android app can get a lot of details about Wi-Fi. However I fail to get protocol type like a/b/g/n. I have a client requirement to do that.
Does anyone know how to achieve that? (I don't have the option to use adb). It is to be done programmatically. I strongly believe that device and router have already negotiated protocol before they can connect. So that information is there with device. Question is, how do we get it?
You can partially deduce the protocol from the link speed
WifiManager.getConnectionInfo().getLinkSpeed()
By Wikipedia 802.11 protocols speed table you can tell if it is 802.11b, 802.11n or 802.11ag.
802.11n and 802.11ac full link speed tables
Link speeds of protocols 802.11a and 802.11g are the same, you can distinguish between them by the used frequency (5GHz or 2.4GHz) in the scan results.
Note that protocol can change during the connection, client and access point do negotiate protocols and speeds but they agree on a list and not on one specific speed.
I don't think there is a way to distinguish between 802.11n and 802.11ac in their overlapping speeds.
I don't believe this is possible to get in a clean manner. The protocols - a, b, g, n, etc - are actually human abstractions of the MAC and physical layer in networks. These are defined as their recognizable letters if they meet certain hardware specifications, both for the device and the network device.
After doing some digging, it seems that Windows phones are able to display this information. When digging into the manner of determining the protocol on Windows, I came across the desktop explanation as well as the Visual C++ implementation via enums. It seems that even the official Windows documentation relies on vendor-provided data and enumerated values, which would lead me to believe that they need to determine hardware specifications beyond what is likely exposed in the Android API.
If you want to determine the protocol yourself, you'll need to understand the link speed as well as the frequency, modulation, and bandwidth.
TL;DR
Likely not possible unless you are working with a rooted phone and can access the hardware specs directly.
Related
I've developed applications which handle a connection between a PC and an Android phone via Wi-Fi. I try to send a lot of data really often. The TCP/IP protocol, which I used, allow me to achieve just low speed - around 1 Mbit/s. I found that with 802.11n standard we can achieve speed up to 150 Mbit/s. I've set my router to use only 802.11n standard, but I didn't notice any improvement.
What level of speed should be expected? I understand that part of data is lost, but is there any better solution? Any ideas? Where can I find some information to better understand this topic?
You should expect much better performance running 11n with TCP/IP, perhaps 20 Mbit/s in a good environment. But since it is radio, the medium is shared between all users of the air so it is not easy to give a good answer that is valid everywhere.
A tool to test your network throughput is Iperf available on Google Market for your Android device and on Sourceforge. You could use this to see if it is your application or external factors that might affect performance.
If you want to debug it further, you could use Wireshark together with a Wi-Fi sniffer card to see individual packets/transmission rates and retransmission.
I am thinking about an application that will establish a mesh network between smartphones on Android and maybe iOS devices. It'd look like netsukuku between smartphones + Voice, Chat, Data, maybe Local network.
Is it possible by GSM? Any GSM architecture restrictions?
Is it possible to connect phones via GSM in android? and/or iOS?
Can I use Android libs to make it or I need direct access to the GSM module to do it??
There is no way to do this under normal conditions and may not be possible without flashing a modification directly to the underlying GSM radio - not something for the fain at heart. On iOS I am going to guess this is completely impossible.
First of all, there are tons of regulations related to wireless usage. In the US, the FCC takes care of that and each country has its sets of rules that luckily, have some common points. If you want to use a cellphone modem in its current frequency range, you have to modify it and it's not "legal". The frequency range it uses are "owned" by the carriers, they pay big bucks to use it. Second, your cell modem is meant to look for a cell tower and "hook-up" to it. It doesn't have what is necessary to do a mesh. This would require rewriting the firmware in the cell modem itself, and this is only if the chipset support mesh networking (I doubt it). Even after doing all that work, you would have to use available radio frequency band (there's not much) to do that and the cell phone modem antenna is probably not supporting it. So, for your mesh architecture to work, you would have to get some hardware work into it.
Here is an idea: you built a little dungle that would connect to your cell through Bluetooth. This dungle would in turn have a longer reach wireless radio in the ISM band which is license free (you still have to go through FCC... certification). But in the ISM band, the transmission power is also limited so, you mesh will still need to be devices not too far appart.
Simpler and cheaper solution: use the internet to connect your devices together. You can use a server in the cloud where all devices register and then can talk together.
I was wondering if there is an API that allows for direct communication between two or more Android devices, particularly for real-time multiplayer gaming. For example, is Bluetooth communication between two devices for the purpose of gaming?
EDIT: I do not have a (reliable) server so I cannot consider it as an option. I am looking for an API that strictly uses direct device communication (so no servers).
http://androidforums.com/android-games/57-mages-multiplayer-android-game-engine-chess-game-included.html
Here is one multiplayer engine i have run across when exploring networking options. I have not used it though so I cannot give any insightful opinion about it.
Generally I tend to lean towards creating my own tcp client / server solution. Of course the best choice for you depends on what type game / application you are looking to make. Generally if you plan to have a good number of users on at a single given time (more than 3+) P2P is strayed away from. That being said i have also yet to see a well working solution for a client / server application over bluetooth, which leaves you with traditional networking strategies.
Yes there are APIs for that now.
"Nearby Connections is a peer-to-peer networking API that allows apps to easily discover, connect to, and exchange data with nearby devices in real-time, regardless of network connectivity."
https://developers.google.com/nearby/connections/overview
Also see:
Wifi P2P
https://developer.android.com/guide/topics/connectivity/wifip2p
Overview on what to select:
https://developer.android.com/training/connect-devices-wirelessly
PS I know this is an old question but it still ranks very high on search engines, therefore I add this answer.
If you're doing Peer-2-Peer, then Bluetooth and/or NFC would be your best bets. I would suggest to using the "Internet" approach through Wifi as it offers more flexibility.
I'm trying to make an app on an Android device that will control an application on an iPad or Android tablet. (I'm testing with an Samsung Galaxy S2 and an iPad 2).
The application is pretty simple for now. When one selects a colour on the Android mobile, that colour displays on the tablet device.
The question is, how to connect the two devices. Just now I've verified that I can pair the two devices using Bluetooth. Also, the Samsung has a "Kies" Wifi Direct feature (which I don't understand fully), that allows the iPad to connect to the Galaxy as a wifi hotspot.
The connections are there, but I don't know if either protocol can be used to actually get the apps to talk to each other to get the control I'm looking for.
Should I be using Bluetooth, Wifi, or something else?
And in whichever case, how?
My opinion is that you should not stick so much around the physical medium used for connectivity either is WiFi or Bluetooth. You should abstract this aspect, in both cases you will be using sockets (I'm speaking about Android), if it's Bluetooth you will be using Bluetooth Sockets, if it's WiFi: TCP sockets. You could have a intermediate layer that abstracts the type of connection and through a factory to use either Bluetooth or TCP.
Bluetooth - http://developer.android.com/guide/topics/wireless/bluetooth.html
For WiFi you should study if P2P would help.
You will need two applications:
- one on the tablet - the server which listens for commands from the client (change color, do this or this)
- second on the smartphone - the client which sends commands.
I've built a few apps that do exactly that between iPhone and iPad. But the principle is the same. I used Bonjour networking. It's just a fancy name for ZeroConfig networking between devices. It's written originally by Apple but it's open source so there should be Android support out there for it too. Really simple and easy to work with.
If you already have a working connection then you already have the first half of your answer, that said you should really consider implementing a solution that uses a variety of connection types, WIFI, Bluetooth, etc.. The question I think you are really asking is how to pass data and messages between the apps once you have the connection.
There are a lot of ways to accomplish this. You could implement your own lightweight message passing system. If you haven't done this before it is more complicated than it originally seems, especially as you would be required to implement the system for each OS you end up using.
Should I be using Bluetooth, Wifi, or something else?
It depends on what situations you want your program to work in.
Bluetooth can provide a direct connection between your devices. A potential issue with bluetooth is that it has a limited range. If you're devices need to be far away from each other, you may want to go with wifi. Otherwise, bluetooth could work great.
If both devices are connected to the internet, you can make them talk to each other through there. The advantage of this approach is that it doesn't matter how far apart your devices are as long as they're both online. A disadvantage is that you'll have to figure out how to find the tablet's ip address before you can talk to it. This is actually a HUGE disadvantage because it can be quite problematic if both of your devices are not on the same wifi. You could have the user type in the destination ip address, but you'll have problems getting it to work if the user is behind a router (which will almost always be the case). The point is, it gets hairy.
If both of your devices are on the same wifi, you can use ZeroConf AKA bonjour (like Dancreek said) to figure out what ip address you need to send info to. I've previously used a library called jmdns (easy to find with google) to implement zero configuration networking. It's good because the user doesn't have to worry about ip addresses... it's intuitive for the user.
And in whichever case, how?
Networking is a pretty big topic, so I can't expand on this question to much. Short answer is, it depends on what method you choose. Search for some tutorials and start by getting one of your devices to send something as simple as an int to the other.
I want to facilitate video-calling from the android device to another android device. My question is that can i connect the android WiFi device with the android WiFi device without any use of internet connection. I want to use it just like the Skype. is this possible or not? if it is possible then how can i implement it...can i get some code snippets as well???? Please give me link to download that app
First, your idea works completely different from Skype, which is completely dependent on a functional Internet connection for its core functionality.
Second, while you could create an ad-hoc WiFi network betweeen two Android devices, their range will be the limiting factor:
WiFi is intended as a short-range wireless medium. There's a reason nobody wanted the 2.4 GHz band (and therefore it is unlicensed): there's a significant noise and signal loss on these frequencies, noticeable even at short range.
Moreover, wireless equipment in mobile devices is engineered for power efficiency - which translates to lower broadcast power when compared to on-the-grid devices.
Also, the antennae in such devices are omnidirectional - this is rather useful for normal use, but again lowers your available broadcast power
Even if you had huge, high-quality directional external antennae connected to each device, pointing very precisely at each other (btw that also means each of them is stuck in one place; see e.g. this for a dish size calculator), you'd need to make some pretty drastic changes to their networking stack, as the latency inherent in long-distance comms will screw up TCP/IP pretty badly.
Even so, the setup would be very brittle, dependent even on the weather (water vapour absorbs significant amount of power in that part of the spectrum).