I am thinking of developing an Android app that would, as part of it's function, send-to and receive-from broadcast messages from all devices that are currently connected to a WiFi network.
While a lot of developers have suggested that such a requirement would need the application to acquire the MulticastLock, there are experiences out there that say:
Acquiring the MulticastLock successfully cannot be relied upon since the acquire() method does not return any status on the operation requested.
And even if you do acquire the lock, it's not guaranteed that the WiFi stack does not filter out packets that are not directed at the device.
There are others that say multicastlock works reliably on versions 2.3.3 and above and that the problem of reliability is only for devices running 2.3.2 and below.
Some of them say nothing is guaranteed (now or for future devices) as support for broadcast and multicast is a chipset controlled functionality and that OEMs have the final say. They cite battery drain being the primary motivation for OEMs to either allow or deny software configuration of the chipset.
So, before i delve into my project, i wish to know what the current state of this issue is and if what i am trying to do is feasible i.e no guess work involved. If there is a work around, i am willing to implement that as long as i know it will work reliably. Kindly share your opinions and experiences. Thanks in advance.
I have used Android apps based on DLNA (like iMediaShare and WDTV Live Media Player) that use multicast for Discovery and Streaming, albeit, this was on JellyBean and not on pre 2.3.3. The apps were able to discover other devices on the network. This could very well be a pre 2.3.3 issue.
Both the apps mentioned above say that their app works with Android version 2.1 or 2.2 and up
Related
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.
Before you mark this as duplicate, there have been so many questions on SO asking about how to connect Android to iOS over bluetooth. Many of the answers say it isn't possible, or it wasn't possible, or it might be. They are also quite a bit old. This question is about answers from actual practice.
I've done extensive research and found plenty of articles saying it is and isn't possible, but it seems like it should be, especially with Bluetooth Low Energy.
So here's my simple Yes/No question: When making an iOS device broadcast as a Peripheral using CoreBluetooth, have you ever been able to connect an Android device as a Central and exchange data?
Yes it is possible. I wrote a test using an iPhone 5 running 8.1 and a One Plus One running Lollipop. The iPhone advertised a custom service and characteristic, the Android connected to it and retrieved the value of the characteristic.
Interesting observations:
When the iPhone app was advertising in the foreground the Android could detect it when doing a scan only for the specific service uuid, and it would work every time.
When the iPhone app was advertising in the background the Android could only detect it if it was doing a generic scan for all devices, it had to connect to every device it could find to see if it contained the correct custom service uuid. And even then it only worked sometimes. I was quite surprised that the iPhone service could be detected at all when it was advertising in the background, considering on the iOS developer site it says peripherals advertising in the background can only be detected by other iOS devices looking specifically for that service.
I'm developing an Android application able to connect to a BLE (Bluetooth low energy) device.
Problem is after connection, when I want to re-connect to an other device, I can't.
The only solution is to off and on phone bluetooth.
(On the iOS app, it works so problems is from Android app).
I get this error :
BLE connection generic error
I there any known bug on Android >=4.0 on BLE connections ?
There are lots of bugs in the bug tracker and the documentation and example are not good.
You have not given enough information to really be able to tell what your specific problem is but the main issue people fall over is thinking that because the api calls are asynchronous you can just use them that way. In practice you need to use them in a synchronous manner e.g. wait for one call to finish before issuing the next. I am not clear if this is by intention of just a buggy implementation but it is the case at the moment.
There are definite issues in the underlying framework / drivers as you can get the system into a state where it want allow Bluetooth to switch off, it want work without switching Bluetooth off and on again, it want work without rebooting your phone, it want work reliably with Wifi enabled. If you go through the bugs list you will find more.
In my opinion it's not at beta standard yet but we have been trying to live with it for the past 9 months and Google look to of stopped working on it as far as I can tell from the updates we have had since the initial release.
I want to add UDP communication to my game to offer a multiplayer experience. Because I want to release my app, it's absolutely necessary that the UDP communication works constantly on all (or at least the majority of) devices (API Level 8+).
I primarily want to use MulticastSockets, but it seems that Multicast is not working correctly on a plurality of devices, and there is no way to fix that.
So I have to find an alternative. One option might be to broadcast UDP communication.
Do targeted Android devices constantly support broadcasting? If not, which other options exist?
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.