Showing posts with label busybox. Show all posts
Showing posts with label busybox. Show all posts

Tuesday, July 13, 2010

Droid Explorer 0.8.7.0

usesdk 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.

selectpathThe 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

Friday, June 25, 2010

Device Information Extras

madb-xunitMy 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

Thursday, June 24, 2010

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.

Showing posts with label busybox. Show all posts
Showing posts with label busybox. Show all posts

Droid Explorer 0.8.7.0

usesdk 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.

selectpathThe 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

Device Information Extras

madb-xunitMy 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.