Bluetooth has been popular for a long time because of its data transfer capabilities and low power consumption for a limited distance. With the advent of Session Description Protocol (SDP), Bluetooth has become widely popular for making custom SDP services and among developers and manufacturers because of its ease in advertising specific data transfer services for different types of information to be transmitted.
Even though Android is the world’s most popular mobile platform, it still runs into peculiar problems of non-discoverability of Bluetooth service when connected to servers other than the Android server. Consider a scenario where a Bluetooth device is configured as a service by SDP and Universally Unique Identifier (UUID) is advertised in some order. Now, when you start discovering this service on Windows as a discovery agent, it will read the configuration in the correct order. However, the same action will not happen if the discovery agent is run from Android as the discovered UUID gets reversed to what has been advertised. For example, Bluetooth service registered on Linux OS with UUID as e8e10f95-1a70-4b27-9ccf-02010264e9c8 will be discovered on Android OS as c8e96402-0102-cf9c-274b-701a950fe1e8. This reversal is done at the hardware level or by the Android Bluetooth SDK—BlueDroid.
The reversal bug still exists in Android and third-party libraries have only given a temporary fix by reversing the id; hiding the important information about reversals. There are some other incompatibilities that exist if there is cross-platform (Linux to Android, Windows to Android) communication. For example, if you have created a server using BlueZ libraries and discovering it on BlueDroid client or any other client, then you should know the details of the registrations of ids (General Service Id, Service Class id, Class id, RFCOMM and L2CAP id) which are necessary for cross-platform and different framework existence on client and server-side. The registered service is discoverable on the platforms which are running BlueZ libraries even if you miss out the service class id. However, the same service will go completely invisible when the registered service id is discovered through Android as either the assigned Service Class id will be NULL or it will be a unique id.
The solution to the above problem is to either reverse the ordering by code or completely flash the BlueZ libraries with the Android operating system. The former is an easy-fix and a viable solution if you are not working with custom device and plan to distribute it later in the future. The later solution involves effort as the Android device will have different hardware components. For example, a Tablet will have a different set of hardware and mobile will have a different set of hardware. Google provides the source code of each trademarked devices. Individuals can compile and build binary if they want to add libraries that will override the existing driver.
Due to these complexities, Google has changed its Android Bluetooth SDK from BlueZ to BlueDroid after the KitKat version. Even though the usage of BlueZ for Android has been discontinued, it still continues to exist and is widely used in Android and other platforms.