[Android Software/Hacking General [Developers Only]] mateorod:
Okay, I can take a look at that a little later...but it is unlikely that just the patches will tell me what I need to know...have you tried you patches you made on the UNpatched build you used to make the build?

If if patches the build you made it from, then the process was correct and the problem is in your build process. If it does not patch your unpatched build, then you likely have a mistake in how you made the patches.

I will take a look tonight though. There is some information in the patch headers which may help me see what's what.

hmmm....I wonder why you had trouble getting the patches? I may have a mistake somewhere. Urinophoria had trouble getting the update to apply as well...it might just be that some of those builds have UTC stamps (how I determine build date) from the 0625...if you have a second please post a log, could you?

Well that sure is a pain....almost 2/3's of our download size is apktool and various aapt for all the prevalent OS's. I would be sad to have to start supporting it for various Android types...that is a major pain that SlimRom is playing with. I looked at what and how they are doing the inversion though, and it is pretty clever...

I guess we have a couple options...we could add SlimRom's apktool. If it comfortably handles all other apks, then maybe we should just do that.

Another, quite drastic, thing we could try is to (gasp) eliminate apktool, as much as possible. Apktool is essentially a kind of wrapper around the smali binaries...we could actually just use baksmali on Mms.apk and SystemUI.apk and most others. The only one I think we for sure need apktool for is the actual framework-res, and even then only for items in the actual resources (I know things like the 'values' folder are there and decompilation is needed to adjust those). I don't think that we can get rid of apktool permanently as we use some mods that need framework-res (voice, for instance. Caldair you still use it tabletUI, right?) but we could mitigate its impact. I have been thinking about swapping the Mms patch for awhile now.

The framework to institute that last idea is actually already built into the autopatcher. When putting together the files.txt (the list of files a prospective mod needs to decompile) you can preface the file with a tilde (~) and the autopatcher will decompile the apk with baksmali instead of apktool.* The one gotcha there (and it is a big one) is that the apk diff patches are made from a different directory level than ones for smali...so the patches are not interchangeable.

I would really like to fix that last gotcha, but it would require rebuilding all the apk patches...maybe someday. It should be easy to try and swap tools, not complicated. Anyway, that is probably a last ditch idea, but I figured since the team was all here discussing it, why not bring up even the wildest ideas. Now that we have auto-update (even though that is probably still pretty buggy...) I am not as worried about file size and downloads as I once was. Now users will only have to download each tool the once...so file size stops being as huge an issue.

I will look much closer at your logs when I have time later tonight Caldair...that is great work and responsible development.

* You can see a list of various actions we have built into the autopatcher on current line 1415. There are options to add file, remove files and various decompiling methods, including things like boot.imgs and ramdisks. There is also a suite of text-editing functions, like awk and sed and sh. OpenPdroid ended up taking over much of this project, but I like to think there is a lot of power still left under the hood.