Develop Reference

Receiving data back from a BLE embedded device on Android

I am working on an Android BLE project. We are using BLE to configure some settings on an embedded device. The embedded device was going to take a long time to come up so I started using BlueSim to emulate the embedded connection.
There are essentially two messages that the Android (I'm requiring KitKat) device sends off to the embedded device. One is to write settings....One is to read the settings.
A Write message is going out to endpoint 0xFFF1 like the following
byte[] data2Send = new byte[11];
data2Send[0] = 0xAA; // signifying this is a write message to device
data2Send[1] = 0x01; // data value
data2Send[2] = 0x38; // data value
data2Send[3] = 0x47; // data value
data2Send[4] = 0x24; // data value
data2Send[5] = 0x01; // data value
data2Send[6] = 0x36; // data value
data2Send[7] = 0x49; // data value
data2Send[8] = 0x0b; // data value
data2Send[9] = 0x63; // data value
data2Send[10] = 0x0D; // CR to indicate the last byte of the packet
characteristic.setValue(data2Send);
boolean status = mBluetoothGatt.writeCharacteristic(characteristic);
Log.v(TAG,"Status is:" + String.valueOf(status));
I had verified this using BlueSim and we have confirmed that this works when transmitting data to the embedded device. We can successfully change all of the settings.
The other message is a Read request of the device so I can know what settings are already in there or to confirm that the settings actually changed.......
byte[] data3Send = new byte[3];
data3Send[0] = 0x55; // Signify this is a start of a READ message
data3Send[1] = 0x42; // Second part of the read designator
data3Send[2] = 0x0d; // Carriage return saying this is the last bit
characteristic.setValue(data3Send);
boolean status = mBluetoothGatt.writeCharacteristic(characteristic);
Log.v(TAG,"Status is:" + String.valueOf(status))
When I send this message over to BlueSim, I see the message on my iPhone and immediately send the settings back out. On Android I see the 11 bytes that are coming back informing me of all the settings! This almost happens instantaneously. Great!
But when we do this on the embedded device I see one byte come back. That's it. Using a debugger on the embedded side we can see all 11 bytes going into the BLE module on the embedded device. If we use a PC rather than my Android device we can see all 11 bytes show up on the PC (the manufacturer of the BLE module has a terminal like app that you can 'sniff' the data with).
The embedded device is an 8 bit micro that is hooked up to a BLE module (TI CC2540 chipset) via a UART so it's obviously SLOWER than the iPhone where BlueSim is running. The embedded device is going to need some time to receive the BLE message, process the request, and shove data back out the BLE module. Is there some setting I have to set in my Android program to allow for a slower response to come back?
I tried downloading LightBlue on iOS and sending that read request out, and we get the same results. We see the first byte of the data packet show up in LightBlue. But only that one.
Any help would be greatly appreciated as always.

It sounds like you are experiencing an issue with the TI Module, not Android. Not sure if its the same issue, but it seems others have been getting headaches from trying to establish connections from Android to the CC254X. See here: https://e2e.ti.com/support/wireless_connectivity/f/538/t/401240

How do Bluetooth SDP and UUIDs work? (specifically for Android)

My understanding is that the SDP is a list of UUIDs that other devices can fetch.
According to this PDF from MIT, "A more general way to think of
SDP is as an information database." Does this mean I can add multiple values to SDP? Since Android has BluetoothDevice.fetchUuidsWithSdp(), how do I set the UUIDs of a device?
Also, what does each section of an UUID mean? UUIDs look like 00000000-0000-1000-8000-00805F9B34FB, but what information does this convey?

An UUID identifies a service that is available on a particular device. So if you call BluetoothDevice.fetchUUidsWithSdp() your BroadcastReceiver will receive the relevant Intent ACTION_UUID containing the device and the service UUID.
The bluetooth specification defines some common UUIDs.
If you don't want to connect to one of these well known services but intent to implement your own bluetooth application, then you have to just generate your own UUID (use uuidgen from a unix console or an online generator) that identifies your application/service.
You can create an UUID instance in java like this UUID uuid = UUID.fromString("785da8ea-1220-11e5-9493-1697f925ec7b");.
So if you create the server side for your bluetooth application on Android you typically do this
BluetoothAdapter adapter = BluetoothAdapter.getDefaultAdapter();
BluetoothServerSocket serverSocket = adapter.listenUsingRfcommWithServiceRecord("YourHumanReadableServiceName", uuid);
And this is where you "set" your UUID. The Android bluetooth API creates the SDP-entry consisting of YOUR application's UUID and name for you. Other devices can now retrieve this entry. Androids bluetooth stack will now associate a bluetooth channel to your BluetoothServerSocket. If you want to connect to this ServerSocket, the connecting side usually connects doing this:
// you will most likely already have this instance from a discovery or paired device list
BluetoothDevice serverDevice = adapter.getRemoteDevice(bluetoothMacAddress);
// connect to your ServerSocket using the uuid
BluetoothSocket socket = serverDevice.createRfcommSocketToServiceRecord(uuid);
socket.connect();
Android will again do the heavy lifting for you: It checks the SDP-Records on the remote device, looks up the bluetooth channel that corresponds to your service's UUID and connects using this information.
There is a common code snippet spooking around here on SO that advices you to use "reflection" to get to a hidden API looking similar to this code:
try {
// this is the way to go
socket = device.createRfcommSocketToServiceRecord(uuid);
socket.connect( );
} catch ( IOException exception ) {
// don't do that! You will bypass SDP and things will go sideways.
Method m = device.getClass().getMethod("createRfcommSocket", new Class[] {int.class});
socket = (BluetoothSocket) m.invoke(device, 1);
socket.connect();
}
Most people try this and it "just works" in their dev environment but you should know what you do using this. You actively bypass the SDP lookup that retrieves the right bluetooth channel to be used with your service and you will end up connecting to channel 1. If you have more than one Service running on the device, things WILL go sideways in this cases and you will end up in debugging hell ;-)
I developed a small middleware called Blaubot to create small networks using bluetooth/wifi/nfc and experienced all sorts of problems on the devices I used to test with (12 models). It was often the case that the bluetooth stack was not fully functional anymore in cases where it got some load or after many connects/disconnects (which you usually will have, if you are developing your app). In these cases the device.createRfcommSocketToServiceRecord(uuid) would occasionally fail and only turning the bluetooth adapter off and on again helped to bring the bluetooth adapters back to life (in some cases only after a full power cycle). If this happens and you use the reflection method, you will probably not have much fun with bluetooth.
But if you know this and keep concurrent calls to the BluetoothAdapter within bounds, bluetooth connections and the adapters will be pretty stable.

android communicating two apps in separate devices

All the questions here point to classes of the same app or different apps in separate processes yet in the same device. I would like to send data to and from two separate apps in two separate devices. I tried using broadcastreceiver but it didn't work. Here is my snippet to send the data.
addressstring = String.valueOf(acrilocation.getText());
if (addressstring != null && addressstring.length() > 0){
Intent intent = new Intent();
intent.setAction(Intent.ACTION_SEND);
intent.putExtra(Constants.LOCATION_DATA_EXTRA, addressstring);
intent.setType("text/plain");
sendBroadcast(intent);
} else{
Toast.makeText(getApplicationContext(), "Enter valid location address", Toast.LENGTH_SHORT).show();
}
but when I receive the data in my other app using the following code snippet, It fails. When I debug the app I get null exception.
Intent intent = getIntent();
String action = intent.getAction();
String data = intent.getStringExtra(Intent.EXTRA_INTENT);
String type = intent.getType();
useraddress.setText(data);
startActivity(intent);
Is there another way to achieve this? I mean to send data to and from another app which is installed in another device?

Connecting over networks that accept incoming socket connections
The usual way to do this between Android devices (or between any peer devices) is to use sockets.
You set up one or both devices to 'listen' for connections on a socket and then accept a connection from the other when they want to communicate (or you can have a dedicated client and server and the client always initiates the connections).
Once the connection is established you can send messages back and forth.
There are many examples of Android client server socket applications, but one I found useful was:
Android Server/Client example - client side using Socket (and its companion server side blog article - link included in the client blog)
Note that you may have to add your own 'protocol' on top of this - for example if you are sending a file of unknown length without any special 'end' character, you may want to add a byte (or several byte to represent an int, long etc) at the start to indicate the length of the transmission so the receiving side knows when it has received everything (or that it has not received everything in case of an error).
Connecting over networks which do not allow incoming connections (e.g. most 3G/4G)
In these scenarios, while there is nothing theoretically stopping sockets working, in practice many mobile operators will not allow incoming socket connections. In addition you would need to find the public IP address of the Mobile, which is possible but is extra complexity. If your solution will only ever run on a single operators network you can experiment and see if it works, but if not you may find it better and easier to use a server in the 'middle':
Device A connectes to server
Device B connectes to server
Device A asks server for addresses of connected devices and 'discovers' device B
Device A send a message for device B. It actually sends the messages to the server with an indication that it is to be sent to device B
The server notifies device B that a message is available for it (using some sort of message notification like Google Cloud Messaging for example, or simply by the devices polling regularly to see if they have any messages).
Device B retrieves the messages from the server
The above will work on pretty much any network that allows connectivity to the internet. It does have the disadvantage of requiring a server but it is likely a necessary approach over most mobile networks.

If you want the two instances of your Android app on two different devices located on the different parts of the world to communicate with each other directly without the server, then the best way to do it is to use Tor Hidden Services. Tor Hidden Services allow the apps to bypass the firewall or NAT (if Tor is not blocked, of course), and the devices can easily communicate with each other without the need for a central server. Here, I will try to give some code examples that you can try. The best library suitable to this stuff is this.
Step 1: Add dependencies to your gradle.build in app module:
allprojects {
repositories {
maven { url 'https://jitpack.io' }
}
}
dependencies {
compile 'com.github.jehy:Tor-Onion-Proxy-Library:0.0.7'
compile 'org.slf4j:slf4j-api:1.7.7'
compile 'org.slf4j:slf4j-android:1.7.7'
}
Step 2: Add permissions (Internet permissions or whatever) to your manifest file.
Step 3(i): Now we will just write the classic Client-Server programs in Java but with added Android and Tor flavor. To test this properly, try creating two different apps. One app will be the server and the other app will be a client. Preferably, you can even install the two apps on different phones.
In this example, we will try to send "Hello from Tor client" string from client app to server app.
For the server side: You can try this function inside any Activity and AsyncTask.
void server(Context context){
//For comments and documentation, visit the original repo
//https://github.com/thaliproject/Tor_Onion_Proxy_Library
String fileStorageLocation = "hiddenservicemanager";;
com.msopentech.thali.toronionproxy.OnionProxyManager onionProxyManager =
new com.msopentech.thali.android.toronionproxy.AndroidOnionProxyManager(context, fileStorageLocation);
int totalSecondsPerTorStartup = 4 * 60;
int totalTriesPerTorStartup = 5;
try {
boolean ok = onionProxyManager.startWithRepeat(totalSecondsPerTorStartup, totalTriesPerTorStartup);
if (!ok)
System.out.println("Couldn't start tor");
while (!onionProxyManager.isRunning())
Thread.sleep(90);
System.out.println("Tor initialized on port " + onionProxyManager.getIPv4LocalHostSocksPort());
int hiddenServicePort = 8080;
int localPort = 9343;
String onionAddress = onionProxyManager.publishHiddenService(hiddenServicePort, localPort);
System.out.println("Tor onion address of the server is: "+onionAddress);
ServerSocket serverSocket = new ServerSocket(localPort);
while(true) {
System.out.println("Waiting for client request");
Socket receivedSocket = serverSocket.accept();
ObjectInputStream ois = new ObjectInputStream(receivedSocket.getInputStream());
String message = (String) ois.readObject();
//Here we will print the message received from the client to the console.
/*You may want to modify this function to display the received
string in your View.*/
System.out.println("Message Received: " + message);
}
}
catch (Exception e) {
e.printStackTrace();
}
}
Step 3(ii): For the client side try this function
//Inputs:
//'String onionAddress' should be the one obtained in server() function.
//It will be printed in the console and it will possibly remain the same
//even if the app restarts, because all the data/cache will be stored locally.
//Also, when you run the code for the first time, Tor will take about 1 or 2 mins
//to bootstrap. In the subsequent runs, Tor will start relatively faster as the
//data will be cached. 'int hiddenServicePort' is the port at which the hidden
//service has started on the server. In our example code, it is 8080. So, pass that here
void client(Context context, String onionAddress, int hiddenServicePort){
String fileStorageLocation = "clientmanager";
com.msopentech.thali.toronionproxy.OnionProxyManager onionProxyManager =
new com.msopentech.thali.android.toronionproxy.AndroidOnionProxyManager(context, fileStorageLocation);
int totalSecondsPerTorStartup = 4 * 60;
int totalTriesPerTorStartup = 5;
try {
boolean ok = onionProxyManager.startWithRepeat(totalSecondsPerTorStartup, totalTriesPerTorStartup);
int socksPort=onionProxyManager.getIPv4LocalHostSocksPort();
if (!ok)
System.out.println("Couldn't start tor in client");
while (!onionProxyManager.isRunning())
Thread.sleep(90);
System.out.println("Client Tor initialized on port " + socksPort);
System.out.println("Client is waiting for the server to get ready");
Thread.sleep(2000);
Socket clientSocket =
Utilities.socks4aSocketConnection(onionAddress, hiddenServicePort, "127.0.0.1", socksPort);
ObjectOutputStream oos = new ObjectOutputStream(clientSocket.getOutputStream());
oos.writeObject("Hello from Tor client\n");
System.out.println("Client has sent the message");
oos.close();
}
catch (Exception e) {
e.printStackTrace();
}
}
It's done. Run your apps and test it. If you get stuck, try consulting here.
So, now your apps can communicate without any central server. Tor Hidden Services are so awesome in these use cases.

You can also use IP6, then you can do a direct socket connection from one phone to the another. I got latency as low as 60ms between two phones on different 4G operators (in the same country though). Note that you have to send some data to avoid getting down switch to lower speed to get such low latency. 10 concurrent ping was enough for me.
The listen side doesn't need any change at all, the client side just has to use an IP6-address:
s = new Socket("2a10:811:21c:22a1:7683:ae1:18c7:9827", 9343);
IP6 seems to be supported by many operators. If not, tor can be a good fallback, if latency isn't a problem.

Is there a way to exclude my Android proxy app from the Data Usage screen?

I have a system app that sets a forwarding proxy inside android devices. The problem is that since all traffic is redirected to that app, the Data usage screen under settings shows as if all traffic is coming from my app and not other apps.
Reading this: https://source.android.com/devices/tech/datausage/index.html helped me understand that you cannot exclude an app from the data usage unless it is built with the system image. (However, VPNService is able to exclude itself from data usage, so if I could find a hack to do this, it would work for me).
When looking at the android system file /proc/net/xt_qtaguid/ctrl it clearly shows that all socket connections are being tagged with my app's uid.
I looked at qtaguid.c (https://github.com/cgjones/android-system-core/blob/master/libcutils/qtaguid.c) and tried to implement the same mechanism but the problem is that I can't even get the file descriptor from my socketChannel. Since android uses SocketChannelImpl, I tried to use reflection to get the fd, but this did not work:
clientChannel = server.accept();
Class<?> clientChannelImpl = Class.forName("java.nio.SocketChannelImpl");
Method method = clientChannelImpl.getDeclaredMethod("getFD", new Class<?>[0]);
FileDescriptor fd = (FileDescriptor) method.invoke(clientChannel, null);
Class fileDescriptorClass = FileDescriptor.class;
Field field = fileDescriptorClass.getDeclaredField("fd");
field.setAccessible(true);
I guess even if this worked, I have no idea how the TAG is generated so that I can switch it out with every connection. I know the last 4 bytes of this tag is the uid of the app creating the socket in hex, but thats about it.
Is any of this even possible? Thank you!

I guess it's too late, but anyway.
You should tag client socket, the one you use to establish a remote connection, and not a server socket.

How do i send information via a setup bluetooth connection

So im working around with bluetooth and trying to figure out how to send two strings via a bluetooth connection. From one android device to another.
I found this guide http://developer.android.com/guide/topics/connectivity/bluetooth.html
but it talks alot about setting up the connection. So i went straight down to the chapter about Managing a Connection. The reason i do this is that in the apps i create i plan to setup the bluetooth connection before opening the apps (via the phones usual bluetooth setup) and then open the apps and send when it is necessary.
So my question is how do i find the bluetooth socket that should be setup? Since that should be what im searching for to create the sending and recieving threads?
Hope this is enough information, else tell what more you need and ill try and answer to the best of my ability.
Best Regards Drakthal

The usual bluetooth setup only pairs between devices, it doesn't create a data connection between them (And even if it would, you wouldn't be able to access this Socket object because it's not created in your process).
After Bluetooth is turned on, you can call BluetoothAdapter.getBondedDevices() to get a set of the paired devices. You can then iterate over them, and initiate a connection to the one you want. You can't avoid the connection creation :( If you want a simplified example, you can look here (An answer I posted a while ago, regarding the whole pairing/connecting/sending/receiving subject with bluetooth).
Once you acquired an open connection, sending the 2 string is easy.
String s1 = "A", s2 = "B";
byte[] buf1 = s1.getBytes(), buf2 = s2.getBytes();
OutputStream os = connection.getOutputStream();
os.write(buf1);
os.write(buf2);
os.flush();
connection.close();