Develop Reference

Android NearBy API terribly slow (~10+ seconds for discovery and connection)

I'm trying to setup a communication channel between two Android phones.
Unfortunately, Google decided to block developer access to Bluetooth adapter MAC address, effectively disabling the entire NFC to Bluetooth handover process (Simple Secure Pairing).
Side note: why? privacy/security gain is minimal to none, especially
if you randomize it! you could simply randomize it when an app requests the MAC and that's it!
This SSP process used to take roughly 1-3 seconds at max and generated great user experience.
Currently, I'm stuck with NearBy which generates a terrible user experience (who's gonna wait 10 seconds just for the initial connection?)
The only options we have left:
Improving NearBy API somehow (~10 seconds average to discover and connect! why Google, why?)
WiFi hotspot - setting an agreed-upon ID as the name, discovering and connecting (~8 seconds average)
Bluetooth - requires a popup to be approved each time, a bit faster but results in bad UX.
Internet - just use the Internet and fall back to local wireless methods (when 4G internet connects much faster than local wireless Android NearBy, you know Google has definitely failed with the implementation).
Is there some secret sauce I can pour onto NearBy to improve it, to be, at least as fast as Apple AirDrop (~4 seconds average)?
Do I have any other options I'm missing?
Thanks!

The definition of absurdity:
Two phones that are 1 meter away from each other with several direct wireless options (Bluetooth/BLE/WiFi) take an average of 10 full seconds just to connect (before data is sent).
Two phones that are 20km away from each other, communicating over cellular data (3G/4G/5G) fully connect after an average of 1.7 seconds! Even after traveling through GSM BTS, proxies, cache, firewalls, BGP routing and other filters.
Google has to do something to fix that (after they disabled the only method to make this faster, using BT SSP, handing over NFC to BT - as they disabled BT MAC address exposure).
My solution right now is to use Internet by default while simultaneously trying to connect via NearBy, as I need a fallback ready to work for some of my clients that don't have a good cellular signal.

Wi-Fi vs Bluetooth for peer to peer connection

I am developing an p2p application in android for an educational project in which I want to form groups android phones of students nearby and exchange sensor data in a university campus.
Now there are some considerations :
Devices will automatically discover each other and upon discovering connect and exchange data.
The process runs for a long time maybe 4-8 hours per day. (process of periodically sensing data and exchanging )
Now the p2p groups can be formed using either Bluetooth or WiFi (Not WiFi Direct, simple UDP packets over WiFi considering phones are connected on campus WiFi).
What are pros and cons of using Bluetooth and WiFi in this scenario in terms of reliability, power usage of phones, scalability and any other you can suggest.

Among other answers and input, I would added this answer.
First of all, before we chose WiFi or Bluetooth we need to find out the difference between those two technologies.
I have made comparison chart that covers some of the important information you might need regarding your project.
Note: There are different versions of Bluetooth's and WiFi, this chart is to represent the the general picture of Standard Bluetooth,
Bluetooth v4 and WiFi. It is always suggested to refer to manufacture
specification of each technology.
From the chart we can conclude that Bluetooth has lower power consumption vs WiFi, but at the other hand WiFi has more bandwidth than Bluetooth.
Range in general is just approximation, a lot of things affecting range like human body, obstacles, location (inside or outside), if inside; structure type and materials used inside the building, noise from other sources and devices etc.
(*) Regarding scalability, I have tested WiFi and Bluetooth v4, both system with up to 8 devices, where one of those is host (group owner, server) device and 7 others are guest (clients). see the figure below.
What regards reliability, with Bluetooth v4 I have had some time connectivity problems, but when it works than every-thing is fine.
Note: Bluetooth v4 is not back compatible with older versions of Bluetooth, so if your host is Bluetooth v4 than all other clients
should have Bluetooth v4 or vice versa.
So I will not say which one is best, but if you need longer battery life and light data communication than Bluetooth is the way. Regardless if it is Bluetooth OR WiFi you might need to start with Bluetooth to and test it, if you are happy with it than keep it, otherwise switch to WiFi.
In case you want to build your own code, the code example I followed and used previously for another university research project. It is based on 8 phones (host and client) as seen in the figure above, we collected sensor information and send it to host phone using Bluetooth 4 connection. The source code we used for that can be found here. The same project has WiFi and other type of connections.
Android official google documentation has some information and code example regarding WiFi peer to peer connection, you can follow with example of the code as well.
Regarding collecting your sensor data and sending those to one device. You could added a method that starts collecting sensor or what ever data, and after connection is established successfully than start sending it over to the other device.
As others suggest https://developers.google.com/nearby is also a way to go.

As you can rely on campus Wifi, I would definitely go with the implementation of Google Nearby APIs in my App as it was designed for such use cases...
The way it works answers your question : it makes all the heavy stuff for you, including choice between wifi or Bluetooth for better performance...

Google Nearby is definitely a good choice. You don't have to tackle all the problems when working with WiFi or Bluetooth directly. But Google Nearby only works when both devices are online and have their screens on. For a more critical review of Nearby have a look at http://blog.p2pkit.io/how-google-nearby-really-works-and-what-else-it-does
If you can not accept these limitations, you should look into other frameworks like http://www.p2pkit.io.
Disclaimer: I work for Uepaa, developing p2pkit for Android and iOS.

Data transfer between two android devices which are on different networks

I am working on one project in which two android devices which are in different network need to transfer some data. Both device will have internet connection. It will be either Wifi or GSM provider.
Consider the following cases:
If one Android device has GSM network and
another device in some other place which has Wifi network
If one Android device has GSM network and another device has GSM network
How to transfer data in such cases?
I don't want to use server in between.
Please let me know how do I solve this issue. Any clue or any links which will help me. So far I didn't find any such things. Please help me...

Short Answer: You're going to have to use a server.
Long Answer: You could use bluetooth if the location is close enough or maybe Wifi Direct although I haven't personally used the latter. Although, ultimately a server will be the best option. If you don't know a lot about backend development I could recommend parse.com as a good service that makes creating backends very easy and has fairly high usage limits before you have to pay.

Unless a device has been configured with an external IP address, which is very unlikely (impossible?) on a cellular network, there won't be a way to directly contact it from an external device. Even on WiFi, most devices will never have an externally defined address.
If you had administrative control over a directly connected and externally addressed router, you could port-forward traffic to a single device, but that's likely not the solution you're after.
A much easier approach is to use one of the services that let you define a back-end w/o a lot of setup or costs. The most popular one is probably Parse.

Broadcasting packets to a phone without a connection

This is sort of an odd question, but I know it is possible.
I am trying to broadcast packets over a specific frequency and I want a phone running an application to pick up on these packets. The phone will not need a connection to any network to do this, but simply have it's wifi turned on. The broadcasting device does not need to get any information back from the phone and delivery of every packet to the phone does not need to be guaranteed, much like UDP.
Where do I start? Is this possible for phones without rooting them. Is there some kind of FCC regulation against doing this (over the standard wifi spectrum).
I know this is possible because it's exactly how routers tell a phone they are available to connect. Thanks in advance for any input.

I'm not familiar with iOS development although similar techniques may exist.
Without root
But requires coarse- and/or fine-grained location permission on Android
You can use WifiManager.getScanResults() to scan for wireless router broadcasts.
The network "name" (SSID) and router MAC address (BSSID) are included in the results. You could broadcast these packets and encode data into these fields.
That said, I hope your messages are short as you'll be getting 38 bytes per packet (32 SSID bytes + 6 MAC address bytes).
Yes, some MAC addresses are special or invalid, but if you're just broadcasting and not actually using them, they can still transmit the data.
With root
Depending on the wireless chipset and driver support, you may be able to put the device into "monitor mode" which gives you access to the raw packet data.
The main drawback is that there is no official support for it.
You might find some hacky ways to do this from a Google search but I wasn't able to find any universal solution that works on all (or even most) devices.

Android: slow network during phone calls

We're working on an app that streams a large amount of data out via UDP for GSM-based phones. The idea is to use it while in conjunction with a voice call. If no voice call is present, things are good. However, if a voice call is active, it seems that most of the data we're sending out simply never makes it, even on HSPA+. If we enable Wifi, then everything is good.
I'm worried that this is a physics problem, rather than a phone one. I ruled out CPU contention by inserting a log statement after we send a chunk of data, and saw that it appeared plenty of times.
Is the 3G radio capable of sending data and voice simultaneously well? We tried a speed test during a voice call and saw a huge drop in bandwidth.

I've run into exactly this problem on AT&T's network in the US. They simply throttle the bandwidth while the call is in progress; whether you're on 3G or H. To see how much you're getting throttled try installing speedtest.net's app and running a speed test during and outside a call.
In the bay area I see data rates as low as 30kbit/s during a call on AT&T's network. On T-Mobile it's not throttled so much (same location). A partner in Israel tried the same test and saw only slight throttling during a call -- he was still seeing 500+kbit/s using the same phone that we tested on in the US. (The same phone that got several Mbit/s outside a call in the US.)
As the poster above points out, CDMA phones can't use data concurrently with a phone call at all (but you said GSM explicitly in your post anyway).

Yes, when you are in a call, there might be not internet connection at all. It depends on the type of network you are in. It would vary from GSM, CDMA, and also the connection type, ie. GPRS, EDGE, 3G or 4G. The 3G and upcoming 4G connections should be able to simultaneous give you network connectivity and voice calling.

Yes, the radio is capable of sending both voice and data simultaneously, but from what I understand its a limitation of the network that your phone uses. If you are on Verizon's 3g network than this is probably your problem. Below is an article that goes into some details about the differences between at&t and Verizon's networks: http://mashable.com/2011/01/11/cdma-umts-att-verizon-networks/

I don't know if this case apply to the operator you are using, but for the operators in my country, they limit the bandwidth used per phone, so if the user use calls and internet connection in the same time, you must subtract the bandwidth used for the phone call, which as i know 48 Kb/s for GSM networks(as maximum) and some of operators limits the call bandwidth for 24 Kb/s and and the total available bandwidth is 64 Kb, so the rest of the bandwidth is used for internet, and i don't know the bandwidth user for 3G networks.
BTW, some phones doesn't support phone calls and internet usage in the same time
all the information above belong to personal information able to be wrong

I do confirm the bandwith is reduced during phone calls unless you are using wifi.
This seems to come from the system, not from the operator. This because it is reported with any hardware / any operator / any country. I have searched for some official documentation regarding that but couldn't find any.
I don't think there is any way to work around that so far.