Device Information Extras

My goal for Managed Android Debug Bridge is not just to port the functionality from DDMS/ADB, but to make it useful to developers.

The original Device in ddms has a dictionary for mount points, but it only has the 3 hard coded m ount points. So if a rooted device, with busybox is connected, then it will pull all the mount points on the system.

 

 

 

This gives some information like this:

rootfs			/			rootfs	ro
tmpfs			/dev			tmpfs	rw
devpts			/dev/pts		devpts	rw
proc			/proc			proc	rw
sysfs			/sys			sysfs	rw
tmpfs			/sqlite_stmt_journals	tmpfs	rw
none			/dev/cpuctl		cgroup	rw
/dev/block/mtdblock3	/system			yaffs2	ro
/dev/block/mtdblock5	/data			yaffs2	rw
/dev/block/mtdblock4	/cache			yaffs2	rw
/dev/block/mmcblk0p2	/sd-ext			ext2	rw
/dev/block/vold/179:1	/sdcard			vfat	rw

Notice how the /system mount is read-only. That is because I also have a method to set the mount point ReadWrite/ReadOnly. Again, this will really only be useful for rooted devices, but it also gives the ability to check what the current “access” of the mount is as well. So Droid Explorer can check if the mount is read-only before doing a file operation, like a delete or create, and it can change the mount to read-write if needed (and if it is "enabled" by the user).

MADB also can transfer files better then regular adb. The ddms library does not handle symlinks, but MADB does. So if you try to copy a symlink, it will resolve it and copy over the original, but still name it what the symlink is.

Pulling multiple files from the device can also easily allow developers to show the total progress for the transfer. For the unit tests, I created a simple ISyncProgressMonitor that writes how many bytes were transferred, out of the total bytes, plus how many bytes are remaining. Here is a sample output, with some data trimmed for space, of a pull of /system/app

Starting Transfer
Syncing /system/app/BugReport.apk
Transfered 23669 of 13334850 - 13311181 remaining
Syncing /system/app/EnhancedGoogleSearchProvider.apk
Transfered 89205 of 13334850 - 13245645 remaining
Transfered 154741 of 13334850 - 13180109 remaining
Transfered 220277 of 13334850 - 13114573 remaining
Transfered 274775 of 13334850 - 13060075 remaining
...
Syncing /system/app/Street.apk
Transfered 10224322 of 13334850 - 3110528 remaining
Transfered 10264332 of 13334850 - 3070518 remaining
Syncing /system/app/Talk.apk
Transfered 10329868 of 13334850 - 3004982 remaining
Transfered 10395404 of 13334850 - 2939446 remaining
Transfered 10460940 of 13334850 - 2873910 remaining
Transfered 10526476 of 13334850 - 2808374 remaining
Transfered 10592012 of 13334850 - 2742838 remaining
Transfered 10657548 of 13334850 - 2677302 remaining
Transfered 10717042 of 13334850 - 2617808 remaining
...
Syncing /system/app/YouTube.apk
Transfered 12817565 of 13334850 - 517285 remaining
Transfered 12883101 of 13334850 - 451749 remaining
Transfered 12948637 of 13334850 - 386213 remaining
Transfered 13014173 of 13334850 - 320677 remaining
Transfered 13079709 of 13334850 - 255141 remaining
Transfered 13145245 of 13334850 - 189605 remaining
Transfered 13210781 of 13334850 - 124069 remaining
Transfered 13276317 of 13334850 - 58533 remaining
Transfered 13334850 of 13334850 - 0 remaining

Working with the SyncService

I have gotten a few more key parts of the Managed Android Debug Bridge done. The SyncService has some important methods completed. I have been able to successfully pull a single file from a device, and push a single file to a device. Still not working is the ability to push and pull multiple files, but that is next.

Even though this is a port of the DDMS library, I have taken it upon myself to make some needed changes to some components. For example, when pulling a file, here is the original ddmslib code:

public SyncResult pullFile(String remoteFilepath, String localFilename, ISyncProgressMonitor monitor) {
  monitor.start(0);
  //TODO: use the {@link FileListingService} to get the file size.
  
  SyncResult result = doPullFile(remoteFilepath, localFilename, monitor);
  monitor.stop();
  return result;
}

Notice the “TODO”, this means that when this method is used to pull a file, there is no “notifications” to the ISyncProgressMonitor since the total bytes is set to 0 in the monitor.start. I took the 5 minutes to actually write the method in the FileListingService that can take a string path, and find the FileEntry object, or it will throw a FileNotFoundException. Once we have the FileEntry, we can determine how much data is going to be transfered. Here is the same method, but in MADB.

public SyncResult PullFile ( String remoteFilepath, String localFilename, ISyncProgressMonitor monitor ) {
  if ( monitor == null ) {
    throw new ArgumentNullException ( "monitor", "Monitor cannot be null" );
  }

  long totalWork = 0;
  try {
    FileListingService fls = new FileListingService ( this.Device );
    FileEntry remoteFileEntry = fls.FindEntry ( remoteFilepath );
    totalWork = remoteFileEntry.Size;
  } catch ( FileNotFoundException ffe ) {
    Console.WriteLine ( ffe.ToString ( ) );
    Log.w ( "ddms", ffe );
  }
  monitor.Start ( totalWork );

  SyncResult result = DoPullFile ( remoteFilepath, localFilename, monitor );

  monitor.Stop ( );
  return result;
}

If it fails to find the FileEntry, then it continues on just like the original does. Here is the FindFileEntry method in the FileListingService.

public FileEntry FindFileEntry ( String path ) {
  String[] entriesString = path.Split ( new char[] { LinuxPath.DirectorySeparatorChar }, StringSplitOptions.RemoveEmptyEntries );
  FileEntry current = this.Root;
  foreach ( var pathItem in entriesString ) {
    FileEntry[] entries = GetChildren ( current, true, null );
    foreach ( var e in entries ) {
      if ( String.Compare ( e.Name, pathItem, false ) == 0 ) {
        current = e;
        continue;
      }
    }
  }
  if ( String.Compare ( current.FullPath, path, false ) == 0 ) {
    Console.WriteLine ( "returning: {0}", current.FullPath );
    return current;
  } else {
    throw new FileNotFoundException ( String.Format ( "Unable to locate {0}", path ) );
  }
}

Another thing that I thought should be modified was the Regex used for the FileListingService. In the original version, it only supports the stock Android ls command. I have modified it to support the stock ls, plus it supports busybox ls as well. This was a selfish act, since it helps me closer to my goal of not requiring busybox in order for Droid Explorer to work.

MADB FileListingService

The Managed Android Debug Bridge is coming along. I did some work on the FileListingService, but messed up the checkin and its now missing some files in the project. This will be fixed tomorrow. The FileListingService is the component that is responsible for ADB request that require file information. At the core, it executes an “ls –l” on the device and parses the return data for the information.

I have made some modifications to the Regex used to parse the return data so that both stock “ls” and “busybox ls” are supported. This means that Droid Explorer will be able to perform some operations on non-rooted devices once MADB is integrated in. The good news is, Droid Explorer + MADB will also be able to detect if busybox is installed on the device. It will also be able to display more detailed information, even more then ADB, when pushing or pulling a file to / from the device.

MADB gives more information to developers when executing remote commands when the file does not exist, or even if an “ls” is attempted on a directory does not exist. It does so by throwing a FileNotFoundException. Otherwise, the specified IShellOutputReceiver will be the way developers will know what is happening in the remote command.

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.

Issue with Visual Studio 2010 and dark color themes

I have recently moved to a dark color theme for all my code editors. It is much easier on the eyes. But I recently came across an issue that I can’t figure out how to correct and was hoping that someone will have an answer.
When the method info box pops up this is what it looks like

Now obviously this is not very useful as you can only read “void” and even that is hard to read. I either need to be able to change the background color of the popup window or the color of the text that is displayed in there.
If anyone is interested, the color theme I am using is based on “Coding Instinct” found on StudioStyles.
Here is my modified version, just has some tweaks that were not in it when I started using it, like the line numbers background was white and when you hover a collapsible block it was white, things like that.

Modified Coding Instinct

Update:

Seems this problem is caused by Visual Studio 2010 Pro Power Tools. It enables the code highlighting in the to the parameter help. Email your congressman to see if we can get a way to fix or disable this.

 

Update 2:

This can be fixed. In the Options->Environment->Fonts and Colors set Signature Help Tooltip Background to a darker color of your choice.

New version of Droid Explorer – 0.8.6.0

A new build of Droid Explorer is available for download

• x86 Web Installer
• x64 Web Installer
• x86 Standalone Installer
• x64 Standalone Installer

There are a lot of fixes / changes to this build, here is a list of them

• fixed missing file in the standalone installer
• added check for minimum .net framework version in to bootstrapper (v3.5sp1)
• increased the service start/stop timeout in the bootstrapper from 30 seconds to 60 seconds
• removed initial strings from download panel labels of bootstrapper
• htc desire / bravo icon added for attached devices - thanks to beadza for identifying the device
• added ability to only install the SDK Tools by running install with /sdk switch
• sdk install mode checks if DE is installed, if not, it switches to full install mode
• bart plugin now also checks the sd-ext mount point for the license.
• added the sd-ext app paths as valid application paths
• added sd-ext app paths to the application backup plugin
• removed anda.pk plugin as the site is dead.
• screencast plugin changed to pull the jnlp file directly from the trunk of the project. If there is an error, it falls back to a "local" file
• fixed issues with spaces in folder names
• motorola backflip icon added for attached devices - thanks to zibiza for identifying the device
• new screenshot app that handles all resolutions. Uses new methods to get the framebuffer data
• adjusted the RGB565 class to better handle other devices for screenshots
• started to implement communicating with adb over TCP like ddms does. – This will wind up being part of the Managed Android Debug Bridge.
• acer liquid icon added for attached devices - thanks to fyodor0218 for identifying the device
• started working on the ability to use existing sdk (not yet an option, but soon)

One of the biggest changes is the communicating with adb over TCP. I started to port the code that the ddmslib uses to directly communicate with adb. This is done over a TCP socket. The current reason for this was specifically for the screenshot plugin. Previous versions only took screenshots of devices that had a screen resolution of 320x480. It, like all the other screenshot applications for android pulled the data from the framebuffer located at /dev/graphics/fb0. The problem with pulling this file with adb pull /dev/graphics/fb0 ./fb0 is the framebuffer contains 2+ frames of data because android implements double buffering. So to display 1 image, applications pull down data for 2+ images. This takes some time to perform, not to mention the time it takes to then render the image from the data. Also a problem is you have to know the screen resolution of the device your reading the buffer for, otherwise you will end up with a garbled image.

Using the TCP method eliminates these problems. First, it only sends one frame of data, so we are not pulling extra, unused bytes, so it speeds up the transfer time. It also sends back the screen resolution of the image, plus other information like the bpp, argb lengths and offsets.

My plan is to move everything that Droid Explorer uses the adb.exe commands for over to TCP eventually. The SDK is still required to be on the machine, but it gives more control to Droid Explorer, and in this case, speeds things up.

Birth of the blog

I have not blogged in a long time, since I took down my old website that had my blog on it about a year ago. I will now use blogger as my blog host as I do not feel like maintaining the software to blog.

I am an Application/Web Developer at UPS in Bedford Park, IL for my day job. In the evenings I am an Android enthusiast, and write applications for the Android platform, Web, and Windows.

What should you expect from this blog? Honestly, it will depend on my mood, schedule and where the stars are aligned. I could post a detailed post on a new android application I released, it could be a short post about a new build of Droid Explorer, or I could post how pissed I am that my sd-card stopped working.

How often will I post? When ever I have something I think is worth posting. I could post 30 times in one day, but not post again for 2 months.

Do I always ask myself questions and then answer them? No, now move on…