Connecting to Nook Color w/ CyanogenMod7 via ADB over USB

The Nook Color is a great device, especially when CyanogenMod is installed on the device. The only issue I was having with the device, I was unable to connect to the device via ADB over USB.

I followed the steps here, but was still unable to see the device via ADB. After looking through the “fix” that was linked from XDA, I noticed that it modifies, or creates a file in %USERPROFILE%\.android\ called adb_usb.ini. That file contains vendor id’s for the devices and it contains 0x2080. As I was digging around looking to fix this issue, I noticed that in the root of my Android SDK installation there is a folder called .android. In that folder, just like the one in my user profile, there is a file called adb_usb.ini. This file is empty, except a couple comments describing the file. I added the 0x2080 to this file, then I restarted adb by doing an adb kill-server, then an adb start-server.

Now when I do adb devices, I can see the Nook Color and I can perform any adb or shell commands on the device via adb over USB.

Droid Explorer 1.0 on Non-Rooted Devices

I hit somewhat of a milestone today. I got the Droid Explorer 1.0 branch to build. Not only that, about 90% of the communication from Droid Explorer and the device is now done through MadBee. That’s the Managed Android Debug Bridge, if you were not aware. MadBee is basically an enhanced port of the Android Debug Bridge library that ships as part of the Android SDK. There are other features that I have added to it, like the ability to check if the device has BusyBox, or if the device can execute SU commands.

MadBee is available from NuGet, but is still very young. I occasionally notice some issues with how things work while using it as the “power” behind Droid Explorer, and go in and make some modifications. But I always update on NuGet, but that means I may update there often.

What, exactly does MadBee mean for Droid Explorer? Well, I am glad I asked. MadBee is the link between the device and Droid Explorer. Since it is based off the original Android Debug Bridge, it was initially meant for non-rooted devices. It has always been my intentions, and goal, to have Droid Explorer working on ALL devices, not just rooted ones. MadBee helps make that happen. Now, MadBee does not circumvent any security that is already in place on your device, so if you don’t have a rooted device, you will not be able to perform any tasks that would require root, like remount /system with read-write.

There is still a lot of work to be done before this build of Droid Explorer will be ready for the public, but here is a teaser of Droid Explorer connected to a non-rooted Galaxy Tab.

Droid Explorer 0.8.8.0 Released

Last night I released a new version of Droid Explorer that addresses some major issues that were introduced with the latest versions of the SDK.

• Fixed the issue with the latest android SDK using “platform-tools” directory instead of “platforms/android-{platformversions}/tools”.
• Fixed the screen shot tool to support newer devices (some are now using 32bpp RGB, instead of 16bpp RGB565)
• Fixed an issue with the Bart plugin license not being detected on the device.
• Fixed the console not working on some devices.
• Added Device icons for the LG G2X and Samsung Galaxy S variants.
• The Google USB drivers have been removed from the installer
• Use existing SDK is now the default and recommended option
• Other minor fixes

Download Droid Explorer 0.8.8.0

As always, there are x86 and 64 bit versions available.

The Standalone version is an “Offline Installer” where the other can download additional files (if you are not using an existing SDK).

The last release of Droid Explorer (0.8.7.2) has ~139,000 downloads since August 21 2010, exactly eight months ago. The plan is for more releases of Droid Explorer, in much shorter time frames again. So lets see if the 0.8.8.0 can exceed the number of downloads before the next release (I doubt it will happen )

Closing an activity by touching outside

I have been working on an application that I want to close an Activity when the user touches outside the activity. Like how you can set the setCanceledOnTouchOutside(boolean cancel) in the android.app.Dialog. The activity I want to close is themed like a dialog so there is an area around the activity that is not “active”.

I was able to achieve the desired effect by overriding the activity’s onTouchEvent(MotionEvent event). This method is called when a screen touch event is not handled by any views.

@Override
public boolean onTouchEvent ( MotionEvent event ) {
  // I only care if the event is an UP action
  if ( event.getAction () == MotionEvent.ACTION_UP ) {
    // create a rect for storing the window rect
    Rect r = new Rect ( 0, 0, 0, 0 );
    // retrieve the windows rect
    this.getWindow ().getDecorView ().getHitRect ( r );
    // check if the event position is inside the window rect
    boolean intersects = r.contains ( (int) event.getX (), (int) event.getY () );
    // if the event is not inside then we can close the activity
    if ( !intersects ) {
      // close the activity
      this.finish ();
      // notify that we consumed this event
      return true;
    }
  }
  // let the system handle the event
  return super.onTouchEvent ( event );
}

Now with that code in place, if the user touches anywhere outside of the dialog style activity, it will close.

Droid Explorer 0.8.7.0

A new version of Droid Explorer was put up for download late last night. This version was initially just a maintenance release and consisted of more code refactoring. But it has since turned in to an actual release since some of the newly added features could be somewhat buggy.

One of the changes, code wise, is that all projects have been upgraded to Visual Studio 2010. Along with that, the WiX installer project now uses WiX 3.5.

I fixed the bug where files would no longer open on your system when double clicked. This may not have been an issue with all ROMs, but with CyanogenMod, it was. It seemed that 95% of the files on the system are marked as  “Executable” in CyanogenMod now.

The biggest change is that you can now specify that you want to use an existing Android SDK, instead of having Droid Explorer download a trimmed down version of the SDK. This is really more for the advanced setup, and if you don’t have the SDK already setup, it is best you let Droid Explorer set it up for you.

Once you select that you want to use your existing SDK, during the install, you will be prompted for the path of the SDK. If the installer is unable to find the necessary components in the selected directory, you will be prompted with a message stating that it is not a valid SDK directory. Make sure you are selecting the root of your Android SDK.

Downloads

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