If I have an Android MidiDevice object, I can get its name or product name like this:
val name = device.info.properties.getString(MidiDeviceInfo.PROPERTY_NAME)
val product = device.info.properties.getString(MidiDeviceInfo.PROPERTY_PRODUCT)
But a request for its serial number always returns null:
val serialNumber = device.info.properties.getString(MidiDeviceInfo.PROPERTY_SERIAL_NUMBER)
This is happening with every device I've tried, including virtual MIDI devices, USB MIDI interfaces and Bluetooth MIDI interfaces. Is this working for anyone else? I didn't find any mention of this property in Google, StackOverflow or the Android IssueTracker.
My goal in showing the serial number is to distinguish in the interface between multiple interfaces of the same model. I'm open to other solutions if there's another way to do that.
I can't speak to Android specifically, but it's rare for MIDI interfaces to have such a serial number.
This is a common problem. If you look at the USB device descriptor (using USBTreeView or similar) for multiple of the same model of the device, you'll see that there is often nothing distinguishing between the two.
Additionally, on the MIDI side of things, there is certainly no guarantee of ID/serial as there isn't even a standard for retrieving such information. I think out of all the MIDI devices I own, only one (APC40) has a serial number accessible via SysEx messages.
All this to say, I don't think that property is going to be reliably populated because there is no device-specific information to base it on in most cases. It might have been added to the Android API for something like RTP-MIDI or similar.
Related
In my application, I implemented the classic Bluetooth according to the official documentation: https://developer.android.com/guide/topics/connectivity/bluetooth.
By default startDiscovery() will scan for all the nearby bluetooth devices. But in many situations user/developer already knows the desired category of devices. In my case, you need to find a specific device that implements the method:
bluetoothAdapter.listenUsingInsecureRfcommWithServiceRecord(SERVICE_NAME, MY_UUID_INSECURE);
Ideally, you need to implement the search and connect two devices in one click. How can I select the desired device from the list of found devices? This is for the convenience of using the application, so you do not have to choose from a variety of unnecessary devices. It will be a kind of filter like in BLE. But we are talking about Bluetooth Classic. How can I use SERVICE_NAME, MY_UUID_INSECURE, BluetoothClass to accomplish this task?
EDIT:
I found several solutions to this problem. But they're all not perfect. For now, I just exclude from the list of devices those that have a device.getType() == 2 (DEVICE_TYPE_LE).
Option 1
Search for a device that broadcasts the service with the same UUID as mine. To do this, use the fetchUuidsWithSdp() method for the found devices. Example implementation: https://stackoverflow.com/a/37070600
The disadvantage of this method. Time. You should wait until you receive BluetoothAdapter.ACTION_DISCOVERY_FINISHED before you make any calls to fetchUuidsWithSdp(). It will take 12-18 seconds. In addition to this one must wait for each subsequent call to fetchuuidsWithSdp() to complete, and then give a call to this method for another device. It will take about 3 seconds per device. In total, it can take a very long time to find the right device.
Option 2
Change the device name to a private key or a special name that the client can use to identify the device.
bluetoothAdapter.setName(name);
The main thing is not to forget to return the device name to the original.
saveName = bluetoothAdapter.getName();
Example implementation: https://stackoverflow.com/a/40138077/4716092
The disadvantage of this method. Changing the device name is not so easy in reality. If you do not return the old name of the device, the user may be upset.
I want to exchange (or only read) the NFC tag ID from one Android device to another but I don't know if I should use peer-to-peer mode or emulate an NFC tag with HCE.
If I use HCE, is the emulated tag ID unique?
What is the better option or is there a simpler one?
Neither P2P nor HCE will provide you a unique ID, least not on any phone I'm aware of. With P2P it's required that the ID exchanged in ATR is random. With HCE the emulated tag ID is usually set to 08h plus a random number. There may be API call to set but I'm not aware of such. But it makes a lot of sense that a phone can not be uniquely identified by just anyone reading.
How can I read the NFC ID of another Android device?
I assume you are talking about the anti-collision identifier/UID here. On the reading Android device, you can use the reader-mode API to access devices in HCE mode:
nfcAdapter.enableReaderMode(this, new NfcAdapter.ReaderCallback() {
public void onTagDiscovered (Tag tag) {
byte[] uid = tag.getId();
// TODO: do something with the UID ...
}
}, NfcAdapter.FLAG_READER_NFC_A | NfcAdapter.FLAG_READER_SKIP_NDEF_CHECK, null);
Is the emulated tag ID unique?
See Stephen's answer. Typically, neither P2P mode nor HCE should provide a unique and stable ID. However, there are some exceptions to this and the point of time when a non-stable ID changes may vary (also see this answer). It could be that:
The device has a secure element and uses the static UID of that secure element.
The device generates a new random UID whenever it is turned on, but continues to use the same UID until it is powered off.
The device generates a new random UID on every activation by an external reader device. I.e. whenever an external HF field is applied to the NFC antenna of the Android device.
Also note that some NFC devices will use randomly generated UIDs that do not start with the random-prefix 0x08.
Can I force a device to use a fixed/stable UID?
Android does not provide an API to influence the UID/anti-collision identifier, so the short answer is no. However, if rooting or creating a custom ROM is an option, there are some possibilities to change the UID and other protocol parameters:
Editing Functionality of Host Card Emulation in Android
Host-based Card Emulation with Fixed Card ID
Should you use the UID to identify (or even authenticate) a device?
No, you should definitely not do this. While you sometimes do not have much choice when you try to integrate a HCE device into some legacy system, you should definitely think about a different design.
First of all, as Stephen already wrote, if an NFC device exposes a fixed/stable identifier, this could possibly introduce a privacy issue as anyone could read and track the ID.
Second, while many systems still use these IDs to authenticate(!) cards, UIDs are not necessarily unique (particularly there are less 4-byte UIDs than cards out there) and UIDs can easily be cloned. See this answer for further details.
I am working with Alert Notification Profile (ANP) in Bluetooth Low Energy between Samsung Galaxy S3 and peripheral device.
I can not find any information related to specific UUID's ANP at Android Developer Site.
But in ANCS Specifications (iOS Developer Site), They define specific UUID's ANCS :
The Apple Notification Center Service is a primary service whose service UUID is 7905F431-B5CE-4E99-A40F-4B1E122D00D0.
I feel worry about this different, so anyone can tell me about :
What is specific UUID's ANP in Android?
P/s : From UUID in Wiki, I know this :
Anyone can create a UUID and use it to identify something with reasonable confidence that the same identifier will never be unintentionally created by anyone to identify something else.
But actually, Google Developer has not confirmed about specific UUID's ANP yet?
The basic Bluetooth is : 0000xxxx-0000-1000-8000-00805f9b34fb.
"xxxx" is Assigned Number you need replace in it, you can declared.
But the other thing, at firmware side also define that UUID for Mobile Application can communicate with Firmware.
You dont need to know the uuid of profile. You need to know the uuids of services belong to this profile. It has one services and the uuid is 00001811-0000-1000-8000-00805f9b34fb
Also yoou need to know the uuids characteristics belong to this services to get the value of them. It has 5 characteristics:
1- New Alert Category : 00002A47-0000-1000-8000-00805f9b34fb
2- New Alert : 00002A46-0000-1000-8000-00805f9b34fb
3- Supported Unread Alert Category : 00002A48-0000-1000-8000-00805f9b34fb
etc..
I guess you are trying to use the Phone to send Alert to an external device ?
If I understand correctly the bluetooth specs, https://developer.bluetooth.org/TechnologyOverview/Pages/ANS.aspx , your Phone is supposed to be turned into a peripheral, not a central to do that.
Peripheral = slave, server
central = master, client
The issue is, android phones can't be turned into peripherals (so far) https://code.google.com/p/android/issues/detail?id=59693
While it is probable that a future update fixes this, it is not an available feature yet.
Of course you could always hack your way into making it available ;-) but that'd be a dirty solution http://blog.cozybit.com/enabling-peripheral-mode-in-android-kitkat-4-4/
I am fairly new to Android Development and i have recently been exploring Usb Host.
Would anyone be able to tell me how to use Bulk Transfer so that i can see what an external camera sees but instead show it on my tablet?
Camera : Canon Powershot A1300
Tablet : Iconia A200
I have looked around stack overflow and some other forums but have not yet been able to find a good explanation on how to use Bulk Transfer or what constants to use as parameters for retrieving certain data.
I am able to see the endpoints and set up a connection with the external camera but I do not know where to go from here.
Any help is deeply appreciated.
The USB Host APIs in Android are fairly thin, by which I mean once you have gone beyond enumerating the interfaces/endpoints and creating a connection it doesn't do much more to assist you. You are then in the realm of communicating with raw USB data transfers, the format of which depend on the device class your camera represents. Your request is somewhat a can of worms, so I will do my best to provide helpful resources.
Unfortunately, storage and media devices are not the simplest device classes to interpret, so it may be difficult if you are just getting your feet wet on USB in general. The best advice I can give is to take a look at the device class specs for the interface class your camera reports (most are either Mass Storage or MTP), which can be found here: http://www.usb.org/developers/devclass_docs
The spec document will enumerate the commands you need to use to communicate with the device. I would also recommend checking out USB In a Nutshell, which does a great job of pointing out how USB requests are constructed in general, which can help you map what you see in a the spec docs to the parameters found in the methods of UsbDeviceConnection: http://www.beyondlogic.org/usbnutshell/usb1.shtml
There will likely be a handful of control commands you need to send to "endpoint 0" initially to set up the camera, and then the remaining transfers will likely take place over the bulk endpoints.
In Android terms, control requests can only be sent synchronously using UsbDeviceConnection.controlTransfer(), meaning this method blocks until the transfer is complete. The parameters that fill in this method are found in the spec docs for your device class.
Requests on bulk endpoints can be sent synchronously via UsbDeviceConnection.bulkTransfer() OR asynchronously using a UsbRequest instance. With UsbRequest you can queue a transfer and then later check back (via UsbDeviceConnection.requestWait()) for the results.
I have some examples on my Github page in using the host APIs to do some basic interrupt and control transfers to get information like device descriptors. Perhaps some of that will be helpful to you as well: https://github.com/devunwired/accessory-samples
With regards to your question about the USB example code:
The request made in this code is just a generic "Get Configuration Descriptor" request that all USB devices must respond to (it's a core command, not class-specific). In fact, its the request where the Android APIs get the information you can query for interfaces and endpoints. The field values come from the Core USB Specification (this command specifically is defined at section 9.4.3 and 9.6.3 in the 3.0 spec): http://www.usb.org/developers/docs/ or a more helpful description you can find from USB in a Nutshell, which has a little more discussion: http://www.beyondlogic.org/usbnutshell/usb5.shtml#ConfigurationDescriptors
The length is somewhat arbitrary, this tells the driver how many bytes to read or write. Most USB host drivers will first query the device descriptor, which includes a field telling the host the Max Packet Size the device supports, and then will use that size as the length for future requests. A full-featured driver would probably make this command and then check the length bytes first (the wTotalLength field of the descriptor) to see if the buffer was large enough, and modify/resend if not. In the example, I just chose 64 for simplicity because that is the "maximum" Max Packet Size the protocol defines as supportable.
Again, then making requests of the specific data your device has to offer, those commands will be found in the specific class document, not the core specification.
Alright here's the deal. I got two Galaxy Nexus phones both with bluetooth enabled.
I've written a bluetooth connection management app that I use for device discovery and connectivity. It also outputs all the available UUIDs the devices can support.
Looking from http://www.bluetooth.org/Technical/AssignedNumbers/service_discovery.htm the following standard UUIDs are exposed from Galaxy Nexus devices.
0x1116 - NAP
0x112f - PBAP (Phonebook Access Profile)
0x111f - HFP (Hands free)
0x1105 - OPP (Object Push Profile)
0x1112 - HSP (Headset Profile)
0x110c - AVRCP
0x110a - A2DP
I am trying to connect via the OPP profile (UUID 00001105-0000-1000-8000-00805F9B34FB) and push objects (files) between the devices. I've gone though the entire Android API documentation on how to discover, pair/bond (threading etc.) and manage all bluetooth connections. I've managed to successfully connect and talk to a legacy board device via the SPP (0x1101) profile.
However, when I try to use socket.connect() between the two galaxy nexus phones, the pairing dialog shows up and I click Pair button on both devices. After that, I immediately get a Connection Refused IOException. Note that after pairing has occurred once I never get asked again which makes sense since the secure link is cached.
If I can't connect to these standard profiles using these standard UUIDs why are they exposed? How can I connect from my app to any of these profiles and interact with them? Is it because my app is not somehow trusted? What's weird is that even the Share functionality on Android does not work at all either. Is this something completely broken on Android?
Please avoid giving me hints to use the "well known UUID SPP one 0x1101" like the docs say. This is not what I want. I have a fairly good understanding of how this stuff works and I am looking for a real solution or explanation of the problem.
I've seen the typical "reflection" solution but I do not understand why is this still a problem on Android? Why do people use reflection to make this work? Can we file a bug on Android to fix this?
If those UUIDs are standard any app should be able to connect and interact with them. Why is this an issue and why do I get this exception?
Thanks in advance.
UPDATE
So for some reason the object push in the Android system started working. I actually attempted to connect via my app and it was not working. Then, I went to the Contacts app and tried to share a contact which magically worked. Then, I went back to my app and it now it works...wow. That is very weird and there must be an explanation to this.
I ran into this same issue and managed to find a solution that worked for me.
In my case I using three different test devices (Nexus 5, Galaxy S4, Note 2) and for some reason, the Note 2 wouldn't connect to my Bluetooth module yet the other two would.
The reasoning I've found is that Bluetooth drivers vary, and slightly different connection methods are needed to create a connection between different devices.
The three methods I use are called 'Secure', 'Insecure' and 'Reflection method'/'hax'.
switch(connType)
{
case Secure:
tmpSocket = device.createRfcommSocketToServiceRecord(_uuid);
break;
case Insecure:
tmpSocket = device.createInsecureRfcommSocketToServiceRecord(_uuid);
break;
case Hax:
Method createSocket = device.getClass().getMethod("createRfcommSocket", new Class[] {int.class});
tmpSocket = (BluetoothSocket)createSocket.invoke(device, Integer.valueOf(1));
break;
}
In my case, the Secure mode worked for both the Nexus 5 and Galaxy S4 however it didn't work for the Note 2.
After some testing I discovered the Note 2 only works using 'Insecure' mode, so to cater to this, I basically attempt a connection and cycle through the different modes if necessary. When attempting a different connection mode I simply prompt 'retrying connection'. So, if the connection fails using secure, then I will attempt using Insecure and then using the reflection method.
I haven't run into the case where one of these three methods haven't worked.
Have you tried using a nonstandard profile? i.e. a custom UUID just for your app. This will also help you know your are (most likely) only connecting to your own app rather than some other app that is registered with the same profile.
From my experience, Bluetooth pairing is very buggy for the first pair attempt. However, using a custom UUID helps this somewhat.
The reflection method (I think) was originally an attempt to fix a bug with a specific device, however I think some people found success in using it elsewhere as well. The device was called the Spica or something similar.
As one of the comments also posted, I would also try connecting again after failing.
Basically write code that plans to fail the first attempt, but then the code tries to connect again in 5 seconds if there was a failure.
These are imperfect solutions but Bluetooth implementation on Android is also imperfect (IMHO). Hope that helps
EDIT
Based on the question update and comments:
I agree something is definitely buggy. Part of the problem I think is the BT drivers vary and each has a different BT stack with different quirks. I also found a question that makes use of both the reflection method AND custom UUID, AND other standard methods. This seems extreme to me but it does cover the most ground. Unfortunately as app developers we have no control over the low level stack/code/drivers.
I have found with my two Bluetooth sharing apps that the first pairing is always tricky.
I'm glad to know it's not just me.