[Android Software Development] iBotPeaches:
A little update for those who frequent this thread, but not so much in IRC. (long-read)

We've been experiencing lots of problems recently with Google Apps and other applications during recompiling, in such ways that they won't install / FC on launch. During a long debugging session, I made a test APK in hopes to replicate the bug that these 100,000 line Google App's have. After making my Test.apk, I finally reproduced the problem that simply rebuilding and installing failed with errors.

Looking at "aapt d resources Test.apk" of the clean apk gives this.

The rebuilt apk has this

So, immediately your eye should catch that in the rebuilt apk the public flag is thrown for every resource. This was required back in Android Froyo as we needed a way to manually set resource IDs which using the `public.xml` file helped solve and is still required today. So I began looking into AOSP build procedure (EX: the process that builds the files into a compiled `resources.arsc` file). Doing so, I found that the AndroidManifest.xml is used multiple times in the procedure for package names and other data.

This led me to an obvious question. Sometimes when we "inject" we only leave a modified resources.arsc in the clean apk, as in we leave the AndroidManifest.xml and other parts alone. So how could the resources.arsc be causing it? Well, after looking into AOSP. It seems during build the decoded AndroidManifest.xml is used for the procedure of creating the binary resources.arsc

I couldn't seem to figure out at this point what was wrong. A print out of `aapt d xmltree Test.apk AndroidManifest.xml` of the rebuilt and clean apk resulted in the exact same file. So if the file is the same, how is it failing?

The next part is just a guess, but its a guess that worked :)

Knowing that our public resource flag(s) were thrown I began looking into AAPT again. Then I stumbled upon a StackOverflow question, where it said "For applications resources, PP is always 0x7f.". PP is the package id. 0x7F is 127 which I remember seeing in the apktool.yml for most apks. Package IDs for applications shouldn't be public, because they aren't meant for the whole system. They should be private for that application only.

When the build procedure goes, its looking for the resource at 0xPPTTNNNN, where PP is the package id. Our process leaves them public (so 0x01 is the PP part), when they are in fact at somewhere else (usually 0x7F or something else for framework apps). This means during the build any [MENTION=936943]string[/MENTION] reference in the AndroidManifest.xml cannot be located. Why we don't get an error is beyond me.

I confirmed this by a hex comparison of the resources.arsc. Except we need the public.xml to prevent resource ID shuffling. (As you know, you can delete the public.xml) and Apktool works fine. However, all resource ids get shuffled which cause more problems than it solves, UNLESS we create a tool to remap the resource ids in the smali (disassembled java), but whoa someone in February of 2011 already had this idea!

Winner winner chicken dinner. We have found the problem, but not so sure on how to solve it efficiently, because the fix "public.xml" that helps us retain constant resource IDs is also causing our problem :(

Using this method (of manually replacing any [MENTION=936943]string[/MENTION] reference in AndroidManifest.xml with the actual value), I've successfully decoded and rebuilt and run without errors the newest Google Apps ranging from the keyboard, searchbox, etc. This method works :)

Thanks to Brut for confirming my ideas that the public flag was related, and having the idea that this might become a problem way back in the day :)

Thanks to [MENTION=4939520]Shaftamle[/MENTION] for his efforts in helping track the problem down via original bug report.

Whew. That was a lot of typing, but a long long time of research. Finally paid off.