[Android Software/Hacking General [Developers Only]] mateorod:
Right now, we have no one building for TouchWiz, Sense, or MIUI. So we don't cover those roms. We could, since I know that at least MIUI and TouchWIz 4.1.1 has released source code. But without someone willing to build the files I need to make patches, they aren't supported. That is littered throughout this thread, but I know it can be hard to find. I try not to overwhelm people with info on the first post, but I will try and be more clear about that.

I am glad it worked for you, it was a dumb typo that didn't get noticed since most people aren't using roms from early October anymore.

I will be happy to explain anything you are wondering about. One of my plans for a future release is to completely rewrite the script with more descriptive variable names and increased commenting, just so people can have a clearer idea of what we do and why.

For what was specifically happening with your problem: Google shipped Jellybean with a major bug, in that the framework.jar was up against a hard-coded limit in Java. There is a upper-limit of how many methods can be in these files (methods are the Java equivalent of functions) and Google was right up next to that limit.

What that meant, practically, was that there was no room for groups as diverse as Cyanogen to Samsung to add their own code to the framework.jar, which is a very important place for people to add functions and improvements. That includes us with PDroid, as we needed to put some of our code in the framework.jar as well.

The solution that everyone started with was to take some easily movable files and split them off into a new file called framework2.jar. You can see here where Cyanogen himself reported the problem/workaround to Google.

However, that only created so much space, and as development on jellybean continued, the space began to fill up. Sometime in late August, all of a sudden we could no longer fit our PDroid methods into Cyanogen anymore, with the AOKP and PA derivatives soon to follow.

Our immediate quick-fix was supplied by friend-of-the-program tonyp, who suggested we delete some carrier-related files called RILs. These files are all included in every build, but roms only need the RILs that work with their specific carrier. So pastime wrote a script that finds out which RILs your ROM needed, and deleted the unecessary RILs, thereby creating enough room for the PDroid methods to squeeze under the cap. That script is called (in our program) framework.jar.sh

That process is what you were actually having trouble with; if you look in your logs before I commited a fix, that script wasn't running do to a typo. The reason it took this long to be noticed is because it is no longer needed for newer roms.

Earlier this month, I saw a user named ninno_mx had discovered, through trial and error, that some methods related to voip could be easily moved to the framework2.jar as well. I knew we needed the space and as also aware that CyanogenMod itself was likely to run out of space soon. PDroid only needs about 250 methods in the framework.jar, and since we had run out of room a month ago, that likely meant CM was only 100 or so methods away from this being a problem for them again as well.

So I submitted a patch upstream moving those other methods, thereby creating the space needed for Pdroid and PDroid2.0. Cyanogen checked it out and merged it in mid-October. That has allowed us to stop deleting the RIL files on current roms. But the older roms don't include the commit, so they still need to have those RILs deleted.

The script wasn't executing because I had somehow deleted the '$' that indicates to the shell that a portion of the path was a variable. That meant when the auto-patcher program looked for the framework.jar.sh script it couldn't find it and so it didn't run it. Therefore, your patching failed.

I can go on for days; the Auto-Patcher has a relatively clear purpose, but in order to keep it flexible and powerful, we have a very complicated process. You should see what we do to enable PDroid patching for AOSP, we essentially create the framework2.jar out of whole cloth, and have to modify the boot.img's classpath so that it knows where to find those classes. I am pretty proud of that one, lol. It is not something many people would ever think to do post-build. Unless you're us and have decided to use the smali binaries for Good instead of Evil.

Hope that helps, although I don't know that it does...