I am writing a local communication system between Android phones that are connected to the local Wifi Access Point.
In the design of my system, the Android phones should notify the owner once they received an UDP broadcast packet from the Windows server.
The system works just fine when the screen of the phone is turned on. But it is found that, once the screen of Android phone is turned off, the phone just ignored the packet, just like no message is received.
I have tried Google for many time, but still no luck. Actually I really don't know what keyword should I use for doing the searching.
Do any one know how can I do what I want? Thank you very much
You will need:
a WakeLock
a WifiLock
a suit of armor, to better defend yourself from users who do not like it that you are keeping the device awake and WiFi radio powered on
Related
We are making a SIP-related solution and I am requested to compose an app on a customized android pad(4.4.*). Unluckily, the pad is from 3rd party and accordingly we hardly do further jobs on the framework or driver......
On the Pad, a LAN port is designed over USB and we plan to access network via LAN. Besides, no power key is populated on the cover.....
Now the question is: Since the pad sleeps, the LAN connection is stopped soon. I fully understand it's a normal behavior that android conducts. I am trying to acquire known wake lock(partial or WIFI lock) to stop USB controller from sleeping ... but, currently, little progress. is there any usb-related wake lock, just like wifi lock ?
I have solved the problem from the perspective of HW .... I am not sure the solution is really meaningful to the current topic. But I think that sharing the idea with you is the major goal of the forum running.
a MOS component is added along the power line controlling Screen. Then I manipulate the connection/disconnection by sending command to MCU....
Based on my experiences , it is really hard to extend functionality on a poor quality of pad ... poor post-sales support.......
Hope you it's helpful to you.
My question is that is it possible to send and receive data between multiple android devices via broadcasting over wifi without establishing p2p connection?
Our professor asked us to design a wireless network system in which you broadcast a message within your android phone, and the other android phones nearby receive it and broadcast it again so that the other phones can receive it and it continues like that. In this way, for example, when someone writes a message in a classroom or café everyone will be able to receive it and broadcast it again. (like an adhoc network system). And although my professor believes it can be achievable, I didn't find anything online like this kind of android network system. So my question is again is it possible to do something like that?
Any helpful leads and references will be appreciated.
Edit: I had to change the title of the question.
I couldn't find a proper solution so I tried the following method so far: I set up a UDP messaging app using Wifi hotspot (it works perfectly for multi clients). The phone who turns on the hotspot is the server and others who connect to it are the clients. Then, I decided to turn this system into an adhoc-like system where there would be more than one hotspot and the clients would connect to them in cycling order and serve as a bridge among these servers.(every second, they will switch to other hotspot and vice versa.) So, they will carry the messages from one network to another. (I know it is very inefficient and prone to time delays; but it is the only idea I have come up with so far.)
When I told this system to my professor, he said that it is too complicated and I just need to broadcast a message from a device to a common channel(without setting up a network connection), and other devices will listen to this broadcast channel(without connecting to a network system), receive the message and broadcast their own messages along with received ones to this channel again as I described in the question body. (he never mentions hotspot, Wifi direct, and etc.) He even told me that the only thing I need to do was to think simpler and use the properties of 802.11. But, I do not think it is that easy to set up such a wireless system, at least for Android where ad hoc systems are not supported yet. So any help will be greatly appreciated. Thanks!
The Nearby Connections API in Google Play Services released last week uses WiFi multicast: https://developers.google.com/games/services/android/nearby
It works for devices already on the same WiFi network. However, it uses a host/clients model, and doesn't work with WiFi direct or a tethered hotspot connection.
You could also use the WiFi direct APIs from ICS: https://developer.android.com/guide/topics/connectivity/wifip2p.html
You can have multiple devices connected together via WiFi direct, so firing UDP packets as #willis suggests would seem the way to go
It is implementable. Do you know the aircrack? similarly, you can receive all packets even not sent to you, and you can send any kinds of packets even not sent by you.
I have a question about C2DM. It is not a configuration, IDs, or usage question. I think I have all that squared away. Instead it is about a specific failure scenario.
I send a C2DM to a device and it does not wake from sleep. It is using AT&T with Wi-Fi disabled and is not plugged into the charger. I think all of those are important things to mention.
When I turn on the device I can browse the internet, sync gmail, and send/receive xmpp packets from within the application I am writing - the same one that embeds the C2DM broadcast receiver.
The device is now in a state where there is an undelivered C2DM messages but otherwise seems to be connected to the Internet and running. At this point if I go into and out of airplane mode I immediately get the “missing” C2DM message.
Question: Anybody else seeing this and have an explanation?
(I’m used to this stuff on WinMo with junky RILs - but don’t know what to try on Android)
Edit One: I understand that C2DM is not guaranteed delivery. But, if it always fails under certain circumstances that is a different thing altogether. I am seeing it fail on sleeping devices and not recovering until I cycle airplane mode. Hopefully this makes my question more unique than one that can be answered with "C2DM delivery is not guaranteed".
Edit Two: I can not reproduce this on a WiFi Xoom against my home router. It is easily reproducible on the Galaxy Tab 8.9 with a stock ROM. Could it be that be AT&T is closing the connection in a way not detected by the C2DM client code and that cycling airplane mode forces a reconnection? That sort of limitation should be documented or considered a bug right?
In my case the problem is the at&t 4g lte APN (at this time in my market)
The APN strongly affects C2DM.
I'm attempting to write an app that involves connecting two android devices via bluetooth.
It is my understanding that one device acts as a server, listening for incoming connections while the other acts as the client, and initializes the connection using the server's MAC address.
Consider the following:
I have my android phone in my pocket, I start working on my android tablet. I want to connect the tablet to the phone (via bluetooth) without taking the phone out of my pocket (I do not want to pull out the phone and manually start listening for incoming connections).
What would be a good way to achieve this? It seems like I would have to make the phone the server, constantly listening for connections 24/7. However, my gut says this will violently drain the battery.
Any suggestions?
You are right, you could make your phone (or your tablet) the server. But it ought not use that much battery; once you set up a server socket and start accepting connections the code simple blocks and waits for an incoming connection. In my experience I haven't found this to be too much of a battery drain (but I have no hard figures to back that up).
If there is a UI involved with the server you'll want to split out the server socket into a separate thread so as to not block UI events.
Typically phones behave this way - i.e wait for incoming connections from paired devices. Waiting / Scanning for incoming connections is less power hungry than trying to find or connect to devices in a poll mode. Many bluetooth chips have low power scan which implements power efficient scanning.
I implemented codes for receiving multicast diagram.
My phone can get a diagram when screen is on.
However when screen is off, phone does not get any diagram from subnet.
(PC sends a diagram on subnet for searching phone.)
I though that multicast lock api(WifiManager.MulticastLock) can solve this problem, but it does not work.
How can I listen multicast diagram, phone screen is off ?
You will also need a WakeLock and perhaps also a regular WifiLock. WifiManager.MulticastLock will not keep the device powered on and may not keep the WiFi radio powered on.