I'm contemplating the development of an Android app that detects all or most nearby mobile devices (iPhone, Android, etc) in the immediate neighborhood that are turned on. I don't need to interact with these devices, just detect them, and a requirement is that the detected devices can't need to have any special / unusual apps installed on them. The app only needs to work for typical U.S. devices and networks.
I've thought about a few ways to do this (somehow detecting bluetooth, wifi, or cellular transmissions / identifiers), but I'm looking for specific implementation methods for a way to detect a relatively large proportion of nearby devices. I'm not sure which of these methods is possible / feasible or how to put them into practice...
Perhaps using Bluetooth: Is there a way using the Android SDK to detect non-discoverable Bluetooth devices (not in discoverable mode)? The Nokia Developer site seems to suggest this is possible using Service Discovery Protocol (SDP), but I'm not sure if this is possible more generally in Android.
Perhaps using cell tower mast switching simulation? Ok, this is almost certainly beyond the reach of Android, but this article suggests that there may be a way to "mimic cell mast switching process to trigger quiescent phones into transmitting. Phones respond with their ID and authentication signals...".
I think you should see this, it is a paper, and you cannot view it for free, but in the summary, it clearly states:
Concerns about Bluetooth device security have led the specification of the “non-discoverable” mode, which prevents devices from being listed during a Bluetooth device search process. However, a nondiscoverable Bluetooth device is visible to devices that know its address or can discover its address. This paper discusses the detection of non-discoverable Bluetooth devices using an enhanced brute force search attack. Our results indicate that the average time to attack a non-discoverable Bluetooth device using multiple search devices and condensed packet timing can be reduced to well under 24 hours.
But for an android application, you need the detection time to be well under a few seconds instead of less than 24 hours, so a practical solution may not yet be available.
Related
We are developing an application that should collect data from multiple Wear OS smartwatches and show the collected informations from all the smartwatches on one Android device.
The aim is to find a solution that does not need the presence of the smartwatches' paired phones, so that the users could leave their phones away.
The other requirement is to avoid the use of internet, so that the application could work even in remote areas or where there is no WiFi hotspot for the smartwatches.
I have found Android Nearby Connections API that seems a good choice when you want to develop a local area network application, but it seems that this API is not compatible with Android's Wear OS. (Even though I am not sure about that...)
I am not sure that Bluetooth could accomplish the task of connecting many devices together, as I read about protocol limit and hardware limit that takes to a maximum of 7 devices connected and only 1 device active per time.
Also, the android docs about Bluetooth connections seems to reference about connection between android and devices, more than android and android.
I am not sure that WiFi direct would work, and, from what I understood, BLE works only for very limited amount of data (in the order of the bytes, we need at least a rate of 1 or 2 kbps, but maybe it would be enough) and I am not sure that would work to connect more android devices together.
So the question is: what is the best solution to create a local area network between one android device (acting as a server / central node) and multiple andoid wear os devices acting as clients / sensors?
I am currently trying to develop a mobile application for both iOS and Android. It basically will be a game buzzer app, determining which of the players is granted a right to answer a specific questions.
The problem is that I struggle to determine which technology / framework I should use for that. Now, some details:
In this app there will be a "base" - it is the phone that gives
"start" signal for all the other players. Each buzzer pressed before this signal corresponds to a false start. Eventually, information
about which player is granted a right to answer or is penalized due
to false start should be displayed on the base device.
App is done for people who have no access to the internet. All the
communication should exists given ONLY mobile phones with no data
plan.
Max number of communicating devices is 9 (1 base and 8 players)
I investigated a lot of resources and this is what I discovered:
Regular WLAN with TCP sockets and etc won't help, since it assumes that all devices are connected to same wireless access point - it violates my requirements.
Regular bluetooth won't help either. This would work across a specific platform, but making Android talk to iOS is impossible.
Situation with Wi-Fi direct is same as with regular bluetooth. Both platforms support this, but Apple's MultipeerConnectivity framework works only with iOS devices.
Now the last option I am left with is BLE. Both platforms support this and are able to intercommunicate (acting both as central or peripheral devices). However, due to my requirements for an app, I assume that base device should act as peripheral, and according to (sometimes conflicting) articles on Internet, one can't connect several central devices to single peripheral.
Now, my questions:
I still assume I might have done some mistakes in the bullet points above, so please, correct me if I am somewhere wrong.
Now when I am left only with BLE option, are there any possible solutions to the above issue? Maybe it is possible to use all devices as centrals (?). I recently saw this example, where everything works cool. Sorry in advance, if I said something stupid.
Of course, there is a counterexample - FireChat, which employs OpenGarden's MeshKit. But the framework is not available. I tried communicating OpenGarden people, but no response. Does anyone know if it is planned to go opensource soon, or maybe there exists any analog of this?
Try the Hype SDK by Hype Labs. It's a multi-transport, multi-hop mesh SDK. It supports interoperable Bluetooth Low Energy (and other transports as well). The SDK is currently in private beta but will be made available upon approval of the subscription.
If I make one device (e.g. Android tablet) indefinitely discoverable and make a second one (e.g. phone with BL 3.0 support) search for devices, it seems like I'll be able to extract server device name (http://developer.android.com/guide/topics/connectivity/bluetooth.html). By device name, I can deduct where in the world is the second device. What is wrong with sucn an approach? (I'm completely new to Android, just validating feasibility of some idea).
The problem with BLE is - 70% of android devices still have OS version < 4.3.
You can certainly do it within limits - I have some software running on my Mac that automatically locks the screen when my Bluetooth phone goes out of range. It doesn't use BLE.
One issue that you will have is the power consumption is greater than BLE, so battery life may be affected.
Another is that as the transmit power of the older Bluetooth can be higher than BLE you may find that the devices stay "in contact" for longer than you would like - It can certainly give you an idea of 'proximity/presence' although not really 'location'.
Also, if you pair the devices then they should be able to scan for one another without needing to be 'discoverable' - this is the approach used by the Mac software I mentioned. I am not familiar enough with the Android BT APIs to know whether you can detect a paired device but then not connect.
Also, taking the device MAC from the advertisement rather than name is probably 'safer' - A user may rename their device, but they won't change the MAC.
We would like to connect sixteen vibrators to an Android phone using Bluetooth, and control the vibrators individually.
As far as I know, you can only have eight devices in a piconet, so that would place a limit of seven vibrators (the phone itself being the eighth device). First of all: Is that correct?
And do up to seven connected devices work well and reliably in Android? Or is there some additional limit or problems from Android's Bluetooth implementation or APIs?
For our sixteen vibrators, will we have to build a scatternet with additional devices that bridge between the phone's piconet and additional piconets with some of the vibrators? Does anyone have experience with this, and does it work well?
(And no, it's not a sex toy!)
As far as I know, you can only have eight devices in a piconet, so
that would place a limit of seven vibrators (the phone itself being
the eighth device). First of all: Is that correct?
Ok to be technically precise - Bluetooth Classic can connect and be in active connection with upto 7 devices
at a time. But then an active device can then be put in park mode and it can have a large number of device in park modes, so device can be moved to park from the connected - active state and vice versa.
But again at any one point you can have only 7 active devices So the master device should manage a large number of devices by keeping (unto 7 ) active and rest parked and keep switching them between active and parked modes.
And do up to seven connected devices work well and reliably in
Android? Or is there some additional limit or problems from Android's
Bluetooth implementation or APIs?
Well in Android the problem is - There is no one implementation and many different bluetooth Radio hardware gets used by different manufacturers. So the answer is it depends. Some are pretty reliable Some are really bad.
But there are no public APIs to control / use the Park mode that I described above - But if you can operate on the internals or have access to it from your app you could do what you are asking for,
On Scatternet :
Again Android does not have any API for you to control it, It will be complicated - but your could force it into a scatternet configuration, but again there are limits - the best I have seen in commercial devices is for a device to be in 2 or 3 piconets at the same time, Which means you can be connected to (7+2) 9 devices at a time (it does not meet your requirement of 16).
Bridging / Mesh configuration may be feasible - Where 2 of your devices form their own piconetcs i.e with 8 devices in each group then the leader of the group (Master) connects to Android deevice - and you manage the data relay at the application.
Now having said all this - have you looked at Bluetooth Low Energy - A perfect candidate to conenct a bunch of sensor devices - Ther is no theoritical limit on the number of devices that can be connected at a time - But practically 16 or even larger is very feasible.
Android currently does not have public APIs for it . (As of Today)
But most (almost all) latest adroid devices comes with Bluetooth Hardware that is Version 4.0 meaning it is capable of Bluetooth Low Energy.
And iOS devices - Mac, iPhone , iPad has great support and developer access / apis for it.
So it will be the way to go, and I am pretty Sure Android will come with developer APIs soon for BLE (atleast I hope so)
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).