[Android Software/Hacking General [Developers Only]] mateorod:
Yeah, you can see the java errors are related to the methods. This was a problem we had with AOSP-jb, which we solved in the same way Cyanogen did, by splitting some of those methods off into a separate framework2.jar.

The amateur-hour explanation of this is that it is a problem with dx, the android tool that generates byte code.

Android is written in Java, because it is a hugely portable language, and is what make Android work on so many devices. Developers write code in what is called "human-readable" language, i.e. C, or python or whatever, and then that code is compiled into "machine-readable" lanuguage, which is binary. But all sorts of different machines use different machine-language. So, traditionally, if a developer wanted to run their program on a different device, they would have to run it through a compiler configured for that device. Those compilers were often proprietary and expensive.

Java adds a secondary step in-between the human-code and machine-code, which is called byte-code. After a dev writes their program, they use the Java tools to compile it into byte code. All byte code is the same, and that is what is actually put on devices, But when a machine needs instructions from a particular chunk of byte code, that code is translated into binary, regular machine language, by the Davlik Virtual Machine, a sort of fake computer that finishes the translation.

This allows Java to be, as they say, written once and ran everywhere, because the needs of your unique device are handled by the virtual machine which occurs on your device instead of on a compiler on the developer's computer.

It may seem like Java just adds an extra step to the translation process, and that would only make it slower. But Java cache's these instruction, and saves the translation to machine code for reuse. Have you ever seen someone try and explain why free Android memory is wasted? That memory is holding cached instructions, so if it is full, that just means that the full amount of instructions is ready to be processed by your machine, with no new translation taking up resources.

This particular problem with the methods is a bug or limitation in dx, the tool that android uses to translate Java's byte code. Java is object-oriented, and the actions undertaken by the objects are methods. Basically, the dx tools is complaining that there are too many possible actions in this jarfile for it to compile. All Cyanogen/AOKP/PA roms (as of today) are probably afflicted.

Google has known about this limitation, and half-heartedly promised various solutions for awhile, before finally taking the position that no program should need to be that large and that devs should just be more responsible and write applications of a manageable size. Which is all well and good, until they release AOSP 4.1 with space for only 250 more methods. If you think we are having trouble with it, wait until an OEM tries to cram Sense in there. Which is why I expect a solution before too long.

The framework2.jar bought some time, and there are some things we are trying to expand that idea. But not every class and method is as easily moved as the ones we moved already.

The above was quick and off the top of my head, so there may be some over-generalization there, but that is basically what is happening and what we are facing. There is the Android-specific step of turning byte code into Davlik Executable code (dex) before installation on device and other specifics but the ideas are all basically the same.

Pastime is working on another solution, and I am working a prayer of an idea that may be a little more ideal long-term. Give pastime some time to work on it, he's gotten us this far. The challenges of bringing PDroid up to 4.+ have never been easy, but we've managed so far...