[Captivate Android Development] Liv33viL:
Isolating The Issues...

Jnks123

As per the PS: in your post I'll have to assume (which I'd rather not assume - I always like to know) that your device is now fully deodexed. - Fantastic !!

From the log file you sent (thank you for the logcat) I see a few potential issues that may have occurred:

1) Long File Names in the Windows OS: Especially on earlier versions of Windows, Windows often doesn't respect the Long File Name structure very well, especially when files with long file names are stacked in sun directories with long file names as well. - There are tweaks to resolve this, but one would have to realize that this exists and how to resolve this. Myself, having an Engineering background in Computers and Networks, am savvy to what I am looking at and realize that one from a user's standpoint, on the other side of the screen, will experience and often be thrown off by not realizing what is happening within the OS itself.

Remedy for the above: Typically when working with an SDK or any type tool that will require access through the Windows environment (ie: Environment Path, etc...) one would want to ensure that the SDK or tool kit of choice will be initially installed into the root directory of the system drive. Example - Android SDK Development Tools will be installed to "C:\Android SDK Development Tools" - (without the quotes) provided there is more than adequate space on the drive for paging and flexing, etc... - The same will be so for any other additional tools that one chooses to utilize.

Additionally, where the copies, backups or files to be pushed to the device are located prior to transferring them via ADB for example. - Manual moving of the files / folders (provided the LFN or Long File Name) are not giving issues to begin with.

2) Hierarchies: Similarly to issue number 1 LFN - having files and folders tucked in deep hierarchies (10-15 levels of sub-directories, for example) could potentially give issue and compound the process of troubleshooting.

Remedy: Similar to Remedy for LFN - shorten the hierarchy for the process you are working with.

3) Java / BusyBox - Assure that all your tools are up to date prior to using them. Some tools will work fine while operating in older builds, but with some updates come bug fixes and enhancements to the tool to "play well with others" so to speak.

Remedy: Prior to using a tool, check to see that the build you are using is current, then check for updates if needed. Before updating "Know Exactly What It Is That You Are Updating" ! - There are times, in many cases, where an update can actually break a perfectly working build. - In a world of "Click N' Go" which we live in today, most fail to read. One will see "UPGRADE" or "UPDATE" and B-Line to the download link, in some cases only to find that they have created an unstable environment by Not Reading and understanding what it is they are doing.

4) Framework Directory: 2 APK files reside in the Framework Directory (There are more than only .jar files here) There is framework-res.apk - and - twframework-res.apk.

As stated in one of my prior posts - [2: Verify the file sizes of each directory /system/app and system/framework are within the scope of what they should be. Compare each directory file size prior to and post the dodexing process. (ie: system/app = 15MB (before with odex files) and system/app = 13.5MB (after without the odex files). You should notice that the "new" directories should be smaller in size.] - One should not only look for the size, but also a file comparison to see that indeed all the files exist in both before / after directories.

Additionally, while working with system files, hot files (live active service files) or any file that runs as a process or service in real time, ensure that the proper R/W access exists within the Parent directory and each of the Sub Directories to the one you are working within.

Ensure that the processes or services have been halted while performing the process (# stop) while transferring back to the device.

Ensure that the directory gets set back to what it was originally R/O and that the permissions are the same for the new files as they were for the ones you are replacing.

In closing - sometimes a good tool will exhibit erratic behavior and not perform as expected at all times. It's always good to have a backup plan, alternative means to complete the task and an understanding of the process.

I hope that this has been helpful in identifying current issue or future issues that have yet to occur...

Peace-