I would like to create app, which would simulate in-comming call on handsfree device based on some app events. I found that there are main two ways. First approach use to create RFCOMM and communicate with HFP over AT commands. Unfortunately I spent lot of time with this approach without success. I'm able to establish RFCOMM but not able to receive any AT commands. Now, I'm thinking to use second approach. If I would be able to simulate in-comming call, it would start vibrate the handsfree automatically. Don't you know, if is possible to do that? Probably to broadcast intent, that phone receiving call?
Related
I was doing some research and wanted to know if it's possible to handle calls of my phone from a device (smart watch, bluetooth headset) that is connected to my phone via bluetooth.
I intend it be able to answer calls that come to phone and make calls from my phone when I give the command to the device and I want that device to act like the bluetooth speaker during the call.
I've seen use cases where it is done but have no idea on how it's done or where to start, Any ideas on this? :)
What you are looking for is smartwatch with a speaker/microphone. You should be able to find plenty of them on internet.
I want to build a simple challenge response protocol in order to authenticate a user to an Arduino via the smartphone (Android and iOS) using BLE. I'm having problems seeing how this would be implemented with BLE. What I want to do:
Arduino sends/broadcasts a challenge
Smartphone receives challenge and computes response
Smarpthone sends response to Arduino
The way I thought about implementing this is to have the Arduino (peripheral and server) start advertising when a button is pressed. Ideally an event would be triggered on the smartphone (central and client) when a certain service shows up. Then the smartphone connects to Arduino, reads the challenge characteristic and writes the response to it. Is this a good approach?
It appears though that it is not possible to trigger an event when a BLE service appears and I would continuously need to scan with the smartphone which is very battery intensive. Not sure how to get around this? Geofencing is not really an option since it can be inside. Maybe detecting if the user is walking, biking, standing still? Any suggestions are greatly appreciated =).
On iOS BLE connectivity looks like this:
initialize CBluetoothManager,
start discovering devices through bluetooth.
when found particular peripheral that u're intrested in, connect to it via core manager and store this peripheral variable in ur Class,
then.. u should STOP discovering cuz it's terrible for batteries ;) (as u said),
after device's found, you can search through services, characteristic and at the end through descriptors <-- IN THIS ORDER otherwise u won't get any of these,
ofc, from now on you're able to store each of these vars in your Class and work with them as you wish to. BLE on iOS's based on delegates and it's own lifecycle, each time when there will be something to read the event will trigger. When you will want to send some msg to Arduino back it shouldn't be a problem. In the partial answer for your question about
'when a certain service shows up. THEN the smarphone connects to
Arduino.'
you have to make steps ABOVE in order to read services. Hope that helps.
I have: 1) An embedded device with a Bluetooth connector that I use with BlueZ, and 2) I have an Android phone that I am writing an application on.
Goal: I want to make sure that when these two devices are near each other, they quickly detect each other and establish communication. Unfortunately, I'm running in to complications of what is feasible on Android and power efficient.
Initial Design: Originally, I've been thinking and implementing the following --
Embedded Device: Constantly in discoverable mode, creates a service with an RFCOMM server running to accept multiple connections.
Android Phone: Listen for Broadcast intents that would tell me when the embedded device (discoverable) is nearby, and then create an RFCOMM client socket to it.
The difficulty I am having with this design is that I do not get intents when I would expect them. Even if I turn the embedded device on and cycle the Android phone's Bluetooth adapter to off/on ... none of these Broadcast intents are received:
BluetoothDevice.ACTION_FOUND
BluetoothDevice.ACTION_ACL_CONNECTED
BluetoothDevice.ACTION_BOND_STATE_CHANGED
The only thing that seems to work is to periodically either have the phone try to connect to the Bluetooth device's RFCOMM socket, or to periodically trigger Bluetooth scans (both power inefficient). This will trigger ACTION_FOUND and ACTION_ACL_CONNECTED. If i shutdown the embedded device, I will receive ACTION_ACL_DISCONNECTED. The issue, again, is that none of these are received if I do not explicitly have the phone try to initiate a socket connection. This is bad for power efficiency on the phone.
Do I have this logic backwards? Should the embedded device keep track of Bluetooth MAC addresses that it has paired with and be the RFCOMM client, whereas the Android application creates a service and is the RFCOMM server just hanging around and waiting for a connection? This seems logically backwards, though... I wouldn't think the Android phone would create a service or be the server to make this happen.
If I go in to my car, it almost immediately manages to establish a connection with my phone. So, I know this is possible!
The concrete questions I have are two-fold: 1) Is there something I am doing wrong with my "initial design" to make it more effective, and 2) Is the 2nd logic I propose what things like cars use to establish quick communication and poll frequently? (since the battery power of the car is not a concern...)
Ok, I watched the Google I/O from 2011 presentation on NFC on peer to peer.
The demo was done on Gingerbread and using the application Sticky Notes found
Now in this demo, both device the onNewIntent() was called at the same time so both devices are trying to share information to one another.
On ICS and above, you have Android Beam..
With Android Beam, you have to touch to trigger the onNewIntent() event that will send the NDef message across.
Now the problem with this is that now to trigger the onNewIntent() on both devices, both user on each device has to "Touch To Beam" at the same time.
Is there a way that when you Touch To Beam on one device, both can have the onNewIntent() to be called?
I am trying to develop an app that will exchange data to each other but for it to work in a nice friendly fashion I need the devices to share the data at the same time once the Touch To Beam has been initiated on one device. I do hope this is possible.
Edit: It looks like this might not be possible to do :(
As far as I can tell, the feature you want is not available over NFC itself. The touch-to-beam/SNEP/NPP transfer is one direction only on Android. The user that clicks his screen will push an NDEF message to the other phone.
What I believe they've done in the video is set up a bluetooth connection with the NDEF message to make the transfer (as you saw in the stickynotes demo). Unfortunately there is no nice API for this.
However, the EasyNFC project promises to be able to allow you to create a bluetooth connection and socket between two phones/applications. Check it out here
I had a try and didn't really like the Touch-to-Beam UI that was still required in the set up of the bluetooth connection. It also didnt really suit my needs, as I wanted to transfer phone to computer and didn't really want to implement NFC P2P and a bluetooth connection.
Did you try this:
Use the Touch to Beam on phone-1 to "PUSH" the data, while on the other (phone-2), use the NDEF_DISCOVERED/TECH_DISCOVERED intent to trigger/start the data capture/reception. I vaguely remember one of the above intents were triggered when a PUSH is done. Although, every transmission requires a "Touch" to start the beaming.
When you think in general, Android should not allow the NFC data transfer in both direction at the same time. Lets think of a scenario where I want to send a thing to my friend with NFC. What is actively open on my friend's phone is not important. I should send this thing even the same app is not open on the receiver side. There may be another app in my friends phone that tries to send another thing to me. When we touch our phones, Android Beam (TM) appears and he data is sent from the phone that is touched.
In you case I think you should disable Android Beam (TM) by setting setNdefPushMessage(null) and do sending both ways using the old way.
https://developer.android.com/preview/api-overview.html
I think it will be available in L!!!
NFC enhancements
Your app can invoke the Android Beam on the user’s device to share data by calling android.nfc.NfcAdapter.invokeBeam(). This avoids the need for the user to manually tap the device against another NFC-capable device to complete the data transfer.
I am creating a single test application which is using sockets to create a connection between two devices and transfer some data (a kind of messaging app).
My question is:
Is there any way which I won't let other devices connect to a device, when it is already connected with another one. For example I have two devices A and B and they are connected. I don't wanna let device C to connect to any of them.
Any ideas how can I achieve this?
Well, seeing how A and B need to be listening in order for C to connect - i.e. something like ServerSocket, simply stop listening for incoming connections once it successfully makes a connection between A and B?
Without your code for how you connect I can't tell much more, but that should be how to do it.