Monday, June 21, 2010

Managed Android Debug Bridge

I have been slowly working on a side project of Droid Explorer called Managed Android Debug Bridge (MADB) and I finally have checked in some code that actually compiles.

MADB is a port of the ddms java library that the ddms uses. This allows communication with the ADB server via TCP and gives more flexibility to developers then calling the adb binary directly. For starters, MADB can request the FrameBuffer, which is what is used to get a screenshot of the device. This is different then pulling /dev/graphics/fb0 because:

  1. that requires root and MADB doesn’t
  2. fb0 contains 2+ frames of data and MADB only gets 1
  3. MADB is faster since its less data to transfer
  4. MADB returns the device screen resolution, ARGB length & offset & bpp. fb0 has none of that information

I have a very small portion of it implemented. Currently, I have the GetFrameBuffer, ExecuteRemoteCommand, Reboot & GetDevices implemented. I’ve actually gone a little further with ExecuteRemoteCommand then the original library, as it checks for the error message that would be displayed if the binary was not found and the method throws a FileNotFoundException instead of just handing the data off to the IShellOutputReceiver.

The goal of MADB is to mimic the functionality that is available via the ddms library and make it available to .NET projects. This project will also be used in Droid Explorer once it has the needed functionality that Droid Explorer requires.

Managed Android Debug Bridge

I have been slowly working on a side project of Droid Explorer called Managed Android Debug Bridge (MADB) and I finally have checked in some code that actually compiles.

MADB is a port of the ddms java library that the ddms uses. This allows communication with the ADB server via TCP and gives more flexibility to developers then calling the adb binary directly. For starters, MADB can request the FrameBuffer, which is what is used to get a screenshot of the device. This is different then pulling /dev/graphics/fb0 because:

  1. that requires root and MADB doesn’t
  2. fb0 contains 2+ frames of data and MADB only gets 1
  3. MADB is faster since its less data to transfer
  4. MADB returns the device screen resolution, ARGB length & offset & bpp. fb0 has none of that information

I have a very small portion of it implemented. Currently, I have the GetFrameBuffer, ExecuteRemoteCommand, Reboot & GetDevices implemented. I’ve actually gone a little further with ExecuteRemoteCommand then the original library, as it checks for the error message that would be displayed if the binary was not found and the method throws a FileNotFoundException instead of just handing the data off to the IShellOutputReceiver.

The goal of MADB is to mimic the functionality that is available via the ddms library and make it available to .NET projects. This project will also be used in Droid Explorer once it has the needed functionality that Droid Explorer requires.