Understanding Android Bluetooth Code : part 1 – Application Framework
At the application framework level is the app’s code, which utilizes the android.bluetooth APIs to interact with the bluetooth hardware. Internally, this code calls the Bluetooth process through the Binder IPC mechanism.
$ git clone https://android.googlesource.com/platform/frameworks/base$ git checkout -b lollipop-release origin/lollipop-releaseImmediate search tells us following files are having code related to Bluetooth, this framework defines the basic package ” android.bluetooth ” which Provides classes that manage Bluetooth functionality, such as scanning for devices, connecting with devices, and managing data transfer between devices.
- Scan for other Bluetooth devices (including BLE devices).
- Query the local Bluetooth adapter for paired Bluetooth devices.
- Establish RFCOMM channels/sockets.
- Connect to specified sockets on other devices.
- Transfer data to and from other devices.
- Communicate with BLE devices, such as proximity sensors, heart rate monitors, fitness devices, and so on.
- Act as a GATT client or a GATT server (BLE).
base$ find . -name *Bluetooth*
File : ./services/core/java/com/android/server/BluetoothManagerService.java
Now, lets understand how this file comes into picture, as we know “SystemServer” starts during booting of android, so during booting “Bluetooth Service Manager” gets added to the initialisation sequence,
Slog.i(TAG, "Bluetooth Manager Service"); bluetooth = new BluetoothManagerService(context); ServiceManager.addService(BluetoothAdapter.BLUETOOTH_MANAGER_SERVICE, bluetooth);refer above code from SystemServer base/services/java/com/android/server/SystemServer.java
above section of code calls “BluetoothManagerService” from ./services/core/java/com/android/server/BluetoothManagerService.java
BluetoothManagerService(Context context) mHandler = new BluetoothHandler(IoThread.get().getLooper());
mContext = context;
mBluetooth = null;
mBinding = false;
mUnbinding = false;
mEnable = false;
mState = BluetoothAdapter.STATE_OFF;
mQuietEnableExternal = false;
mEnableExternal = false;
mAddress = null;
mName = null;
mErrorRecoveryRetryCounter = 0;
mContentResolver = context.getContentResolver();
mCallbacks = new RemoteCallbackList();
mStateChangeCallbacks = new RemoteCallbackList();
IntentFilter filter = new IntentFilter(Intent.ACTION_BOOT_COMPLETED);
filter.addAction(BluetoothAdapter.ACTION_LOCAL_NAME_CHANGED);
filter.addAction(Intent.ACTION_USER_SWITCHED);
registerForAirplaneMode(filter);
filter.setPriority(IntentFilter.SYSTEM_HIGH_PRIORITY);
mContext.registerReceiver(mReceiver, filter);
loadStoredNameAndAddress(); /* Retrieve the Bluetooth Adapter’s name and address and save it in the local cache */
if (isBluetoothPersistedStateOn()) < /* checks if previous saved state is ON */
mEnableExternal = true;
>
int sysUiUid = -1;
try sysUiUid = mContext.getPackageManager().getPackageUid(“com.android.systemui”,
UserHandle.USER_OWNER); /* USER_OWNER : A user id constant to indicate the “owner” user of the device, defined at core/java/android/os/UserHandle.java */
> catch (PackageManager.NameNotFoundException e) Log.wtf(TAG, “Unable to resolve SystemUI’s UID.”, e);
>
mSystemUiUid = sysUiUid;
>
That means, above service just prepares the bluetooth functionality. Logcat messages, might look like below,
D/BluetoothManagerService( 453): Loading stored name and address
D/BluetoothManagerService( 453): Stored bluetooth Name=null,Address=null
I/SystemServer( 453): Bluetooth Manager Service
I/PackageManager( 453): Running dexopt on: com.android.bluetooth
W/PackageManager( 453): Unknown permission com.google.android.gallery3d.permission.GALLERY_PROVIDER in package com.android.bluetooth
W/PackageManager( 453): Unknown permission android.permission.MMS_SEND_OUTBOX_MSG in package com.android.bluetooth
D/BluetoothTethering( 453): startMonitoring: target: Handler (com.android.server.ConnectivityService$NetworkStateTrackerHandler)
D/BluetoothTethering( 453): startMonitoring: mCsHandler: Handler (com.android.server.ConnectivityService$NetworkStateTrackerHandler)
D/BluetoothManagerService( 453): Message: 20
D/BluetoothManagerService( 453): Added callback: android.bluetooth.BluetoothAdapter$1@2c6a7810:true
D/BluetoothManagerService( 453): Message: 30
W/ContextImpl( 453): Calling a method in the system process without a qualified user: android.app.ContextImpl.bindService:1543 android.bluetooth.BluetoothPan.doBind:149 android.bluetooth.BluetoothPan.:141 android.bluetooth.BluetoothAdapter.getProfileProxy:1190 android.bluetooth.BluetoothTetheringDataTracker.startMonitoring:116
D/BluetoothManagerService( 453): Message: 20
D/BluetoothManagerService( 453): Added callback: android.bluetooth.IBluetoothManagerCallback$Stub$Proxy@2c3f0ae8:true
D/BluetoothManagerService( 453): Message: 300
D/BluetoothManagerService( 453): MESSAGE_USER_SWITCHED
The above messages gets printed from, services/core/java/com/android/server/BluetoothManagerService.java, function ”
public void handleMessage(Message msg) if (DBG) Log.d (TAG, “Message: ” + msg.what);
switch (msg.what) >
these messages are declared at the initial of file.
private static final int MESSAGE_REGISTER_ADAPTER = 20;
private static final int MESSAGE_REGISTER_STATE_CHANGE_CALLBACK = 30;
private static final int MESSAGE_USER_SWITCHED = 300;
./core/java/android/bluetooth/BluetoothManager.java
High level manager used to obtain an instance of an BluetoothAdapter and to conduct overall Bluetooth Management. ( Refer Link to check actual functions defined by this class )
File : ./core/java/android/bluetooth/IBluetoothManager.aidl
/**
* System private API for talking with the Bluetooth service.
*
*
*/
interface IBluetoothManager
IBluetooth registerAdapter(in IBluetoothManagerCallback callback);
void unregisterAdapter(in IBluetoothManagerCallback callback);
void registerStateChangeCallback(in IBluetoothStateChangeCallback callback);
void unregisterStateChangeCallback(in IBluetoothStateChangeCallback callback);
boolean isEnabled();
boolean enable();
boolean enableNoAutoConnect();
boolean disable(boolean persist);
IBluetoothGatt getBluetoothGatt();
String getAddress();
String getName();
>
File : ./core/java/android/bluetooth/BluetoothAdapter.java
Represents the local device Bluetooth adapter. The BluetoothAdapter lets you perform fundamental Bluetooth tasks, such as initiate device discovery, query a list of bonded (paired) devices, instantiate a BluetoothDevice using a known MAC address, and create a BluetoothServerSocket to listen for connection requests from other devices, and start a scan for Bluetooth LE devices.
Logcat messages :
D/BluetoothAdapter( 605): 741632288: getState() : mService = null. Returning STATE_OFF
D/BluetoothAdapter( 605): 741632288: getState() : mService = null. Returning STATE_OFF
This messages comes from following section of code,
/**
* Get the current state of the local Bluetooth adapter.
*
Possible return values are
* ,
* ,
* ,
* .
*
Requires
*
* @return current state of Bluetooth adapter
*/
public int getState() try synchronized(mManagerCallback) if (mService != null)
int state= mService.getState();
if (VDBG) Log.d(TAG, “” + hashCode() + “: getState(). Returning ” + state);
return state;
>
// TODO(BT) there might be a small gap during STATE_TURNING_ON that
// mService is null, handle that case
>
> catch (RemoteException e)
if (DBG) Log.d(TAG, “” + hashCode() + “: getState() : mService = null. Returning STATE_OFF”);
return STATE_OFF;
>
User Interface & Control of Bluetooth :
All Bluetooth user control things are defined in below files,
Android debugging over bluetooth (without root)
So I’m on a train to Reading and wanted to continue working on an app I’ve been hacking at but my USB cable is annoyingly inconvenient and Ubuntu keeps throwing a fit because I haven’t been able to configure it to properly handle MTP enabled devices. To get debugging going here’s what I’ve just done.
Connect the phone via USB and from the terminal enter (to run adb in tcp ip mode)
Now on the phone enable debugging from Settings -> Developer options -> enable debugging.
Next enable bluetooth and pair the phone with the laptop. Once paired, unpair the two and on the android device go to Settings -> Tethering and portable hotspot then enable «Bluetooth tethering»
Now go back to settings -> Blutetooth and repair the device with the laptop.
On Ubuntu click your network icon in the task bar to list the available networks
In Ubuntu click the network icon again after successfully connecting to the bluetooth network and click «Connection information» towards the bottom.
From the window that opens, note the Primary DNS IP. Copy it, write it down, whatever you need to but you need it for the next step.
Now from the command line again enter:
adb connect 192.168.44.1:4455 connected to 192.168.44.1:4455
Now if you’re using Eclipse, Intellij or any other IDE with adb support you can look at logcat to start seeing logs from the device:
From here on you can deploy your App to the device and/or debug it without a USB. And obviously each time just pair the devices and reconnect. You won’t have to repeat all the steps — just those two.
Below are a series of screenshots that might help. They’re in no particular order, I’m writing this post on the train and taking screenshots on the phone and laptop and uploading from both directly to the same post so it is what it is but should hopefully still be useful.
Any questions, suggestions, feel free to ask.
Android debugging via Bluetooth
I was using earlier adb to debug Android applications over wifi, usb — it was great. Right now I am wondering if it is possible to connect phone with adb via bluetooth. I did a quick research but didn’t find anything — have you tried it already ?
2 Answers 2
It is not supported by the current adb software, however you could probably make it possible if you have a rooted device (or possibly even if not — see below) either by modifying adb or by using bluetooth to tunnel a channel it does support, such as tcp.
You would need to obtain the source for the adb program — the same source is used to build both the PC and the device versions. First step is to just build it with unmodified functionality, which may take a fair amount of build system modification unless you do so as a part of a complete android source build (the way it was intended to be done)
Then you would modify it to add a bluetooth channel as an option and install it on the device (why you need root) and in your path on the PC. You’d think you could run it from an alternate location on the PC, and you likely can as long as you use it from the command line, but if your fire up DDMS it may kill off the running adb server and launch a new one using the default in the path, so ultimately you’ll have to put your modified version there.
IF you can already get your device to accept adb connections over tcp (possible with root, perhaps possible in some cases without) there is another option, which is to not modify ADB (or at least not modify the device side) and instead come up with something running on the device which accepts bluetooth connections and forwards the traffic via local loopback to the tcp port on which the stock adb is operating. This would save the trouble of having to rebuild adb.
If you have some kind of tethering or similar network-over-bluetooth solution, you might even be able to leverage that to carry adb-over-tcp-over-bluetooth without writing any code.
Finally note that it is not 100% essential that the adb daemon run as a more privileged userid or be installed in place of the official one — you can run an adb daemon as an ordinary application and do many of the expected things with it. However, whichever adb daemon is running first will grab the unix domain java debug socket, and so only that adb daemon will be able to provide the full java debug services. More primitive things like logcat, shell, running process list, push/pull, etc will at least partially work without this, provided that your adb daemon doesn’t quit (modification may be required) when it is unable to claim the debug socket. If you can kill the official adb daemon and exploit a race condition, you may be able to get an unofficial one started before it restarts — you would probably need to have a script or program to do this and run it with setsid from the official adb shell, meaning you’d need to connect via USB first. At that point, you’d also be able to start your unofficial adb daemon running as the same userid as the official one.
You may want to spend some time estimating or testing if the performance (speed) will be satisfactory before investing in a lot of time setting this up for real.