Does anyone know how to discover a BLE Service by UUID in Android? There is a discoverServices() method in Android, but there seems to be no way to discover one individual Service instead of all of them. In Bluetooth, discovering all Services takes a 'long' time, whereas discovering individual Services based on UUID does not take as long. It takes even longer for Android because Android also discovers all the Characteristics and Descriptors as well.
TL;DR: you can't - if you don't want to do some really ugly and potentially dangerous hack.
There is no easy way to do this. If you look at what discoverServices() does on Nougat, you'll see it calls GattService:L1454.
void discoverServices(int clientIf, String address) {
enforceCallingOrSelfPermission(BLUETOOTH_PERM, "Need BLUETOOTH permission");
Integer connId = mClientMap.connIdByAddress(clientIf, address);
if (DBG) Log.d(TAG, "discoverServices() - address=" + address + ", connId=" + connId);
if (connId != null)
gattClientSearchServiceNative(connId, true, 0, 0);
else
Log.e(TAG, "discoverServices() - No connection for " + address + "...");
}
The key here is gattClientSearchServiceNative:
gattClientSearchServiceNative(int conn_id,
boolean search_all,
long service_uuid_lsb,
long service_uuid_msb)
If search_all is true, it will scan everything. If not, it will search only a service with the provided UUID and its characteristics and descriptors.
You could actually try and use reflection to call this directly passing a false search_all parameter and a valid UUID, but that's a really bad practice and will end up crashing when a new version comes out and the internal implementation of this class changes.
Related
Been struggling with connecting to WiFi network in Android 5 and 6 for a while and other similar questions don't seem to work for me. I could get the same code working in Android 4.4.2
Adding the code snippet below.
String networkSSID = getSsid();
String networkPass = getNetworkPass();
WifiConfiguration conf = new WifiConfiguration();
conf.SSID = "\"" + networkSSID + "\"";
conf.status = WifiConfiguration.Status.ENABLED;
conf.priority = 40;
conf.allowedProtocols.set(WifiConfiguration.Protocol.RSN);
conf.allowedProtocols.set(WifiConfiguration.Protocol.WPA);
conf.allowedKeyManagement.set(WifiConfiguration.KeyMgmt.WPA_PSK);
conf.allowedPairwiseCiphers.set(WifiConfiguration.PairwiseCipher.CCMP);
conf.allowedPairwiseCiphers.set(WifiConfiguration.PairwiseCipher.TKIP);
conf.allowedGroupCiphers.set(WifiConfiguration.GroupCipher.WEP40);
conf.allowedGroupCiphers.set(WifiConfiguration.GroupCipher.WEP104);
conf.allowedGroupCiphers.set(WifiConfiguration.GroupCipher.CCMP);
conf.allowedGroupCiphers.set(WifiConfiguration.GroupCipher.TKIP);
conf.preSharedKey = "\""+ networkPass +"\"";
int value = mWifiManager.addNetwork(conf);
Log.i(TAG_CHECK, "Connecting to : " + value);
boolean enabled = mWifiManager.enableNetwork(value, true);
Log.i(TAG_CHECK, "enabled to : " + enabled);
mWifiManager.reconnect();
And here is what I noticed.
mWifiManager.addNetwork(conf)
returns some (+) integer with Android 5(phone) and Android 6(tab).
But both don't connect unless I open the wifi settings (I don't have to do anything and just landing there connects) or I manually turn off and turn on Wifi from the top bar to automatically connect.
The listeners to detect connection to the network are in tact for both the versions to precisely know when the connection get established - confirming the above behaviour. Have attached a pic of the permissions granted below.
Any pointers as to what I am missing?
EDIT: Upon digging into WifiManager class, looks like the Access Point remains in WIFI_AP_STATE_DISABLED state. I should also highlight that everything worked as expected while trying on a different Android M phone.
EDIT2
I have the following observations.
1. The issue so far is specific to 1 android 6.0.1 Samsung tablet and 1 android 5.0.2 Micromax phone. It works just fine on 3 other android 6.0.1 phones, 1 android N phone and Android 4.4.2 phone.
2. The access point ends up in wifi_ap_disabled state in the problematic cases consistently. Both addNetwork and enableNetwork calls are affirmative.
3. These access points are not that of a router wifi but that of other phones that broadcast. The problematic phones can programatically connect to wifi hotspots (setup manually and not in the programatic way as I would like to) without any issue.
4. Mobile data enabled/disabled state or wifi state with a different connected network doesn't change the dynamics for both working and problematic phones.
This makes me think that it is a combination of phones/tabs (and not OS) and the access point broadcast configuration. Do you think I should be playing around with some config parameters?
Edit 3 - Important Update
So the wifimanager is obtained like below
WifiManager mWifiManager = (WifiManager) getSystemService(Context.WIFI_SERVICE);
I instantiate mWifiManager in a service (inside onCreate method) and use that later to scan and connect with inputs from front-end activity. While it doesn't work in the way as described earlier, using the same snippet seems to work when the enableNetwork call is done right in the onCreate method - working just as expected. It also works fine when called from front-end activity but only when I don't instantiate mWifiManager in the service.
Though I would expect only one reference to a system service - WifiManager i.e, I think the subsequent usage of that reference (or a different reference to WifiManager) gets a lower priority (or gets deprioritized by the previous reference) and hence doesn't get completely executed leaving the access point in disabled state and requiring manual intervention to help complete the execution by WifiManager and other wifi system services.
Also, I notice the same in Android 5.0.2 phone, the asynchronous enableNetwork does get executed, but it takes some time to execute it.
My questions
1. It is no more a question about the correctness of the code. Services in general have lesser priority compared to front-end threads So, is there is way I could prioritise the enableNetwork call so that it gets immediately executed?
2. What happens in case of multiple references to WifiManager?
I believe if you add a disconnect() it will do what you want. I've added a check here because addNetwork() can fail to add your network. For Android 6.0+, you can't add a network if it exists already but if this fails you can try getting the network id then connecting. (For instance, it will be there if added (and saved) if you re-install) I also do not add quotes to SSID in Lollipop (ver 21)+.
int value = mWifiManager.addNetwork(conf);
// need to check the result if successful
if (value == -1) {
return; // network not added successfully
}
Log.i(TAG_CHECK, "Connecting to : " + value);
mWifiManager.disconnect(); // add a disconnect
boolean enabled = mWifiManager.enableNetwork(value, true);
Log.i(TAG_CHECK, "enabled to : " + enabled);
mWifiManager.reconnect();
My application requires the ability to know the fundamental audio route the user has selected. On iOS this is trivial, as you just register for a callback and you know exactly where the audio is going.
On Android I was pleased to see the MediaRouter class, however to my dismay it turns out there is no predictable way to determine the route type. For example, when switching to a Bluetooth A2DP device, the only identifying item is the RouteInfo.getName() method, but this returns the friendly name of the A2DP device, so it is impossible to compare against.
I also have tried using the following broadcasts:
AudioManager.ACTION_AUDIO_BECOMING_NOISY
Intent.ACTION_HEADSET_PLUG
BluetoothHeadset.ACTION_AUDIO_STATE_CHANGED
BluetoothA2dp.ACTION_PLAYING_STATE_CHANGED
BluetoothA2dp.ACTION_CONNECTION_STATE_CHANGED
However this method is error prone. For example, if you are connected to Bluetooth A2DP, then you plug in headphones, it is easy to tell the route is "Headphones", but then when un-plugging the headphones you have to guess what route is still active, by recording the connected state from all Bluetooth events.
There are also difficulties in ascertaining the initial audio route when your application starts. HEADSET_PLUG is sticky, so that's good, but nothing else is...
Any suggestions on how to approach this and accurately detect this? And why is this such a difficult task in Android?
Here's a very hackish way of polling for the current route, which also supports detection of A2DP. Use at your own risk, as the interals of these classes could very well change in the future. It should work on Jellybean and Jellybean MR1, though.
String ouputDeviceName;
try {
MediaRouter mr = (MediaRouter)getSystemService(Context.MEDIA_ROUTER_SERVICE);
Class mediaRouterClass = Class.forName("android.media.MediaRouter");
Method getSystemAudioRouteMethod = mediaRouterClass.getMethod("getSystemAudioRoute");
RouteInfo ri = (RouteInfo)getSystemAudioRouteMethod.invoke(mr);
Class mediaRouterStaticClass = Class.forName("android.media.MediaRouter$Static");
Field staticField = mediaRouterClass.getDeclaredField("sStatic");
Field a2dpField = mediaRouterStaticClass.getDeclaredField("mBluetoothA2dpRoute");
AccessibleObject.setAccessible(new AccessibleObject[]{staticField}, true);
AccessibleObject.setAccessible(new AccessibleObject[]{a2dpField}, true);
Object a2dpRoute = a2dpField.get(staticField.get(null));
if (a2dpRoute != mr.getSelectedRoute(MediaRouter.ROUTE_TYPE_LIVE_AUDIO)) {
// Phone, Headphone, HDMI, etc..
ouputDeviceName = "name: " + ri.getName().toString();
} else {
// Audio is routed to A2DP
ouputDeviceName = "name: A2DP";
}
} catch (Exception e) {
e.printStackTrace();
}
I have 2 Android devices using WiFi Direct. On one device I can get information about the other device using the WifiP2pManager class, and request a connection to the other device. However when I request a connection, the other device pops up a little window and asks the user if they want to accept the connection request.
Is it possible to auto-accept these connection requests? I.E to be able to connect to the other device without user confirmation?
It can be easily done with the help of Xposed framework. You just need to replace the single method inside one of android java classes (see the link from snihalani's answer). But of course to use Xposed your device must be rooted. The main idea can be expressed in the following code (using Xposed)
#Override
public void handleLoadPackage(LoadPackageParam lpparam) {
try {
Class<?> wifiP2pService = Class.forName("android.net.wifi.p2p.WifiP2pService", false, lpparam.classLoader);
for (Class<?> c : wifiP2pService.getDeclaredClasses()) {
//XposedBridge.log("inner class " + c.getSimpleName());
if ("P2pStateMachine".equals(c.getSimpleName())) {
XposedBridge.log("Class " + c.getName() + " found");
Method notifyInvitationReceived = c.getDeclaredMethod("notifyInvitationReceived");
final Method sendMessage = c.getMethod("sendMessage", int.class);
XposedBridge.hookMethod(notifyInvitationReceived, new XC_MethodReplacement() {
#Override
protected Object replaceHookedMethod(MethodHookParam param) throws Throwable {
final int PEER_CONNECTION_USER_ACCEPT = 0x00023000 + 2;
sendMessage.invoke(param.thisObject, PEER_CONNECTION_USER_ACCEPT);
return null;
}
});
break;
}
}
} catch (Throwable t) {
XposedBridge.log(t);
}
}
I tested it on SGS4 stock 4.2.2 ROM and it worked.
I guess the same could be done with the help of Substrate for android.
From my current understanding of the API, You cannot really accept connections automatically without user's intervention. You can initiate a connection, that doesn't require user intervention. If both of your devices are mobile devices, you will have to accept connection request on one end.
I have put this as a feature request in android project hosting.
You can monitor their response here: https://code.google.com/p/android/issues/detail?id=30880
Based on the comments, do you really need to connect to the devices if you just want to track and log the vehicles around you ?
I don't know the scope of the project, but you could simply use the WifiP2pDeviceList that you get when you request the peers in the WifiP2pManager. You could get the list of the devices (~= vehicles) around you and could log this.
Connection is useful if you want to send more detailed information I guess.
If you can modify the framework, you can ignore the accept window and direct send the "PEER_CONNECTION_USER_ACCEPT".
Base on Android 5.0, "frameworks/opt/net/wifi/service/java/com/android/server/wifi/p2p/WifiP2pServiceImpl.java".
You must find the "notifyInvitationReceived", and modify to ...
private void notifyInvitationReceived() {
/*Direct sends the accept message.*/
sendMessage(PEER_CONNECTION_USER_ACCEPT);
/*
... old code
*/
}
I need to know UUID on API 8 (2.2) or possibly 2.3.3.
As I understand the documentation, this should be allowed:
phoneDevice = blueAdapter.getRemoteDevice(phoneAddress);
ParcelUuid[] phoneUuids = phoneDevice.getUuids(); // Won't compile
Eclipse gives me:
"The method getUuids() is undefined for the type BluetoothDevice."
But see:
http://developer.android.com/reference/android/bluetooth/BluetoothDevice.html#getUuids()
Also, I would like to know how the UUIDs are "parceled" inside the ParcelUuid[]. In case I ever manage to get there, how do I retrieve a UUID from a parcelUuid[]? Documentation for Android bluetooth seems to be very poor, in my opinion.
What a joke!
Now I try to get it from the intent, but this too gives: *"EXTRA_UUID cannot be resolved or is not a field"*:
intent.getParcelableExtra(BluetoothDevice.EXTRA_UUID);
You have to use reflection to use the getUuids() and fetchUuidsWithSdp() on android version < 3. So, try the code:
Method method = phoneDevice.getClass().getMethod("getUuids", null);
ParcelUuid[] phoneUuids = (ParcelUuid[]) method.invoke(phoneDevice, null);
//this will support from API level 15 and above.
Broadcast Action: This intent is used to broadcast the UUID wrapped as a ParcelUuid of the remote device after it has been fetched. This intent is sent only when the UUIDs of the remote device are requested to be fetched using Service Discovery Protocol
Always contains the extra field EXTRA_DEVICE
Always contains the extra field EXTRA_UUID
Requires BLUETOOTH to receive.
Constant Value: "android.bluetooth.device.action.UUID"
//no way to degrade its hardware related. there is no supporting jar also. http://developer.android.com/sdk/compatibility-library.html
Unfortunately, I don't think there is any good way to get the UUID's supported by a BluetoothDevice with API level < 15. I guess that's why they added the new functions in API 15.
Note, from the docs for BluetoothClass
BluetoothClass is useful as a hint to roughly describe a device (for
example to show an icon in the UI), but does not reliably describe
which Bluetooth profiles or services are actually supported by a
device. Accurate service discovery is done through SDP requests, which
are automatically performed when creating an RFCOMM socket with
createRfcommSocketToServiceRecord(UUID) and
listenUsingRfcommWithServiceRecord(String, UUID).
So, perhaps the device class could be used as a hint as to what services will be available until you perform one of the listed functions. Certainly it doesn't hurt to check the class since this won't require any additional bluetooth operations.
Note that the service class is also available (it is part of the device class) but this is just a general class, not a listing of specific services (like from SDP).
try BluetoothAdapter class
any question, read: http://developer.android.com/reference/android/bluetooth/BluetoothAdapter.html
In case you can not get UUID from getUuids() method. Please try the other way.
After scanned successfully, you should receive byte[] (scanRecord), so from this result, if you can recognize UUID format you can split step by step to get correct UUID as these codes.
P/s : Important thing, you should know UUID format to get from index correctly.
// Put item into hash map
// UUID from index 10 to 24 : 12233445566778899aabbccddeeff0
StringBuilder mSbUUID = new StringBuilder();
for (int i = 0; i < scanRecord.length; i++) {
// UUID
if (i >= 10 & i <= 24) {
if (Integer.toHexString(
scanRecord[i]).contains("ffffff")) {
mSbUUID.append(Integer.toHexString(scanRecord[i]).replace("ffffff", "") + "-");
} else {
mSbUUID.append(Integer.toHexString(scanRecord[i]) + "-");
}
}
}
In my code I am using requestRouteToHost() method:
Does this routing means changing the WIFI to 3G or vice versa??
My code is not working...
public static boolean isHostAvailable(Context context, String urlString) throws UnknownHostException, MalformedURLException {
boolean ret = false;
int networkType = ConnectivityManager.TYPE_WIFI;
ConnectivityManager cm = (ConnectivityManager) context.getSystemService(Context.CONNECTIVITY_SERVICE);
if(cm != null){
NetworkInfo nf = cm.getActiveNetworkInfo();
if(nf != null){
networkType = nf.getType();
}
URL url = new URL(urlString);
InetAddress iAddress = InetAddress.getByName(url.getHost());
ret = cm.requestRouteToHost(networkType, ipToInt(iAddress.getHostAddress()));
}
return ret;
}
public static int ipToInt(String addr) {
String[] addrArray = addr.split("\\.");
int num = 0;
for (int i=0;i<addrArray.length;i++) {
int power = 3-i;
num += ((Integer.parseInt(addrArray[i])%256 * Math.pow(256,power)));
}
return num;
}
Thanks
I think this is an extremely poorly documented method, and while an above comment saying "consider it a ping" might be a reasonable interpretation, I don't think it's correct. The fact that it takes an int as a host address suggests it is a much lower-level method than that, and the comment in the JavaDoc This method requires the caller to hold the permission CHANGE_NETWORK_STATE is another clue, suggesting that this makes a change in the internal routing table of the device. This link provides a better explanation:
requestRouteToHost() doesn't establish connectivity on any network, it
only ensures that any traffic for the specified host will be routed
via the specified network type (wifi or mobile). Connectivity must
already exist on the specified network.
This explanation makes MUCH more sense, considering the permission required. It also appears that it will not work with WiFi. So, it appears what this method is useful for is the following: You wish to ensure that the connection made to a particular host will be made via a SPECIFIC interface and that interface is not WiFi. This might make sense for a long-term, low traffic, battery efficient connection, such as when you wish to keep a socket open to a server and wait for the server to send the occasional message. The mobile data interface would make more sense than WiFi, since you wouldn't need to keep the WiFi radio active the whole time, and the mobile network radio is always on anyway. Incidentally, this is EXACTLY how an iPhone's server "push" mechanism works: It keeps a socket to an Apple server constantly connected over the mobile data interface, waiting for the server to say something.
So, in opposition to the (currently chosen) correct answer, I suggest that the answer to the asker's question: Does this routing means changing the WIFI to 3G or vice versa?? is actually, "Yes, sort of!" If the method returns true, the caller is assured that connections to that IP address will happen over the indicated interface.
And to Google: Boo on you for not documenting some of your APIs better!
Method requestRouteToHost() does not change wifi to 3G or vice versa!
Official Documentation :
public boolean requestRouteToHost (int networkType, int hostAddress)
Ensure that a network route exists to deliver traffic to the specified host via the specified network interface. An attempt to add a route that already exists is ignored, but treated as successful.
Parameters
networkType the type of the network over which traffic to the specified host is to be routed
hostAddress the IP address of the host to which the route is desired
Returns
true on success, false on failure