[Android Software Development] Jarmezrocks:
Right....well you can do that, but you need to have all of your hex offsets bit aligned. Basically because smali is like an assembly language, you will notice that everything is referenced at bytecode addresses. These all add up to a required byte count for that declared register. When you remove something or add something sometimes the memory for that register does not align with the values when it was decompiled.

If you add something you need to go and balance all the registers and then make sure that the total isn't more than the amount allowed to be called.

i.e If the total memory count goes over by a factor and is more or less it won't compile. These byte factors are 4, 8 and 16bit per register. If you're out by 8 bits to make the next whole factor amount then you have to reallocate the total bytes to align to the next amount. It can be really really really confusing at times:eek: Trust me I know....

You should read some resources on understanding the Dalvik Opcodes...although I fear that it may confuse you even more like it did for me.

http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html

When you click on that link, ensure that your gf has a box of kleenex on standbye :silly::p...sorry sorry I know not cool :crying:

Anyway to make this as brief as I possibly can and to make things as clear as mud for you, essentially Smali allows you to see the memory failure offsets and by what byte value that they are failing by. The good part is that as you get the hang of it, it doesn't require any additional thinking. You just need to focus on the memory offset in the first displayed error, once you balance that then you can move on to the next. The good part is that because these are done by byte factors or ratios a lot of the errors can fix them selves. By that I mean if you push a register forward to its next available memory block it can have a toppling effect push maybe 3 or 4 more with it until next one has an incorrect bit value.

Google has a reference on it too, it may not seem as comprehensive but sometimes comprehensive is not better, comprehensive is confusion. In otherwords Google do a good job at simplifying the over all message about what goes on with the Dalvik VM. When what they have isn't enough then look on to more resources till you find what you need ;)

Besides all of the heartache I have now bestowed upon you and the many lost hours of your life coming up. I would just try something really weird and out there with a flashable morph from recovery. I would grab your compiled classes.dex as well as any of the XMLs you've changed and put em in a flashable morph zip and go your life in recovery! :good: What have you got to loose?

Being that it's settings it can only corrupt the apk and it will crash...so just have adb on standby so you can push an original one to your device when it does. For some reason after all the work I do with smali and apktool and not successfully compiling I can sometimes have a win with morph on top.

If you get really stuck then shoot me through your framework and your apk you are trying to mod as well as any decompiled XML resources that you have changed that I can just swap in and I will make you a package to try flash. If it works then decompile the apk straight away and have a look at the output from apktool and you may discover a lot that you would never have learned otherwise. My personal thoughts and opinions of morph is great to get something done, but nothing is learnt from the process that can be applied to future situations. Its like some sort of magic occurs