Add support for apks with different resources package and manifest package (--rename-manifest-package)

[GoogleCodeExporter]

If you use --rename-manifest-package option to aapt when building resources 
something weird happens. Resources are built for old package name, but manifest 
uses new one. This makes resources broken a little when using current apktool, 
because they're built for new package name, so resulting apk is a little 
different than original one.

In most cases it doesn't matter because resource package name isn't that 
important. However in some cases it is, e.g.:

  - I think framework apks with changed resource package shouldn't work anymore
  - if apk declares its own attrs and uses them in XMLs, they're referenced by package name, so references are broken after decoding - you won't be able to build apk back.

Problem can be reproduced very easily: just create new Android project, define 
some attr, use it in XML and then build resources with 
--rename-manifest-package. You will be able to apktool-decode resulting apk, 
but you will get "error: No resource identifier found for attribute" errors 
when building back.

Proper solution to this problem is to revert manifest package back to original 
one. So:

  - check if resources package is different than the one in AndroidManifest.xml
  - if so then rename android:package to that found in resources.arsc and store original android:package in apktool.yml
  - when building use --rename-manifest-package if it is found in apktool.yml

Also in the case of apk-with-attrs files it should be possible to fix the 
problem quite easily without apktool support: just replace 
"http://schemas.android.com/apk/res/${originalPackage}" with 
"http://schemas.android.com/apk/res/${renamedPackage}" in all XML files. You 
can do this in unix by e.g.:

find res -type f | xargs perl -pi -e 
's/http:\/\/schemas.android.com\/apk\/res\/com.touchtype/http:\/\/schemas.androi
d.com\/apk\/res\/com.touchtype.swiftkey/g'

Original issue reported on code.google.com by Brut.alll on 6 Dec 2011 at 12:34

[GoogleCodeExporter]

Yep, need to fix this for 4.2. It seems lots of APKs are starting to do this. 

Original comment by connor.tumbleson on 18 Nov 2012 at 5:38

• Added labels: Priority-High, Milestone-v1.5.1
• Removed labels: Priority-Low

[GoogleCodeExporter]

It's already there in 4.1.2 APKs. Eg. I just tried to decode 
GalleryGoogle.apk+GalleryGoogle.odex. So far so good, it didn't produce any 
errors. Then I tried to build it back into an APK and got tons of the "No 
resource identifier found for attribute '...' in package '...'" errors.

Original comment by zsolt.mu...@gmail.com on 18 Nov 2012 at 7:15

[GoogleCodeExporter]

The suggested workaround/fix worked though.

I had to run the following to replace in the resource XML files the 
"com.android.gallery3d" resource package name with the actual package name 
(from the manifest), which is "com.google.android.gallery3d":

find res -type f | xargs perl -pi -e 
's/http:\/\/schemas\.android\.com\/apk\/res\/com\.android\.gallery3d/http:\/\/sc
hemas.android.com\/apk\/res\/com.google.android.gallery3d/g'

Original comment by zsolt.mu...@gmail.com on 18 Nov 2012 at 7:28

[GoogleCodeExporter]

I can confirm this will work.
Only thing I had to do also is add:

parent="@*android:style/TextAppearance.Medium"

to line 168 of the styles.xml file of the GalleryGoogle output.

Original comment by jvisser1...@gmail.com on 18 Nov 2012 at 9:03

[GoogleCodeExporter]

Issue 227 has been merged into this issue.

Original comment by connor.tumbleson on 18 Nov 2012 at 9:09

[GoogleCodeExporter]

My previous statement was a bit premature. The search&replace in the decoded 
resource XML files works only as far as apktool's build command is involved. 
I.e. the "apktool b GalleryGoogle GalleryGoogle.apk" command completes 
successfully, but putting the rebuilt APK on the phone and launching the camera 
app, it crashes, when I switch to camcorder mode.

However grabbing classes.dex from the rebuilt APK and putting it into the 
factory APK (i.e. unzipping the original APK, putting the classes.dex -that I 
took from the rebuilt APK- into the unzipped folder, rezip the contents of the 
folder into a new APK and sign the APK) works indeed.

So I guess I'll have to wait for Brut.alll's proper solution. Until then I'll 
have to manually do the APK rebuild so I can add the --rename-manifest-package 
option to the aapt commandline. I just checked the current state (from the GIT 
repo) and it seems the fix is not yet there. Hopefully it'll make into the 
1.5.1 version. :-)

Original comment by zsolt.mu...@gmail.com on 25 Nov 2012 at 6:36

[GoogleCodeExporter]

Issue 357 has been merged into this issue.

Original comment by connor.tumbleson on 26 Nov 2012 at 3:56

[GoogleCodeExporter]

About 70% with this little patch. All is going well currently. Just lost a bit 
of time tracing down an AXmlPullParser problem, which ended up being the fact 
that the namespace isn't attached to the package name in AndroidManifest.xml 
which made it quite difficult to grab. Slight oversight on my part.

All that aside. Things are going well. Haven't had as much time as I wish.

Original comment by connor.tumbleson on 29 Nov 2012 at 3:07

• Changed state: Started

[GoogleCodeExporter]

Just a quick question, is there any support yet, or fix/workaround for 
decompiling android 4.2 framework-res.apk? I posted issue 357 in comment 7 so 
you can find the errors. It simply errors at "decompiling sources" and thats 
it. 

Thanks!

Original comment by solitary...@gmail.com on 8 Dec 2012 at 10:59

[GoogleCodeExporter]

Apktool correctly grabs the renamed and original package name and stores it in 
apktool.yml

packageInfo:
  cur_package: com.android.inputmethod.latin
  orig_package: com.google.android.inputmethod.latin

Now, we simply rename the manifest to cur_package, but during build use 
--rename w/ orig_package.

Should have a Apktool v1.5.1 Pre Release 2 ready in a few days.

Original comment by connor.tumbleson on 14 Dec 2012 at 3:17

[GoogleCodeExporter]

I believe I have finally fixed this, testing continues but otherwise its Fixed.

Original comment by connor.tumbleson on 19 Dec 2012 at 2:11

• Changed state: Fixed

[GoogleCodeExporter]

may i get my hands on it? i would like to do some testing as well :)

Original comment by solitary...@gmail.com on 23 Dec 2012 at 1:45

[GoogleCodeExporter]

http://miui.connortumbleson.com/other/apktool/test_versions/apktool_1.5.1PR2.jar

Apktool v1.5.1 PR 2

Original comment by connor.tumbleson on 23 Dec 2012 at 1:57

[GoogleCodeExporter]

:o OMG it worked! No errors!! :D OMG i love you BEST CHRISTMAS PRESENT EVERR! 
:D thanks so much you seriously are amazing!!! :)

Original comment by solitary...@gmail.com on 23 Dec 2012 at 2:11

[GoogleCodeExporter]

So I managed to decompile, change /res/values/colors.xml, then doing find res 
-type f | xargs perl -pi -e 
's/http:\/\/schemas.android.com\/apk\/res\/com.touchtype/http:\/\/schemas.androi
d.com\/apk\/res\/com.touchtype.swiftkey/g' and finally compile, sign and 
install. But everytime I want to open SwiftKey's design settings, I get an FC. 
Anyone knows why? :(

Original comment by SvartSyn...@gmail.com on 26 Dec 2012 at 11:46

[GoogleCodeExporter]

I tried to use new version Apktool v1.5.1 PR 2. But I didn't understand where I 
need to put this string "--rename w/ orig_package".
I used this command:
C:\Users\admin>apktool b --rename w/ com.touchtype.swiftkey c:\1\6

If I build an app as usual (with this command: C:\Users\admin>apktool b c:\1\6) 
but with new version of apktool, the command works, but there are still errors.

Example:
c:\1\8\res\values-v14\styles.xml:4: error: Error retrieving parent for item: 
Noresource found that matches the given name 
@*android:style/Theme.DeviceDefault.Dialog'.

P.S. packageInfo:
  cur_package: android
  orig_package: com.touchtype.swiftkey

Original comment by alex....@gmail.com on 10 Jan 2013 at 12:18

[GoogleCodeExporter]

That has nothing to do w/ the --rename. Its automatically done. Thats just a 
bug according to styles.xml.

Post a new bug with apk and full error log.

Original comment by connor.tumbleson on 10 Jan 2013 at 12:41

[GoogleCodeExporter]

OK, I've attached the log and the folder, which I want to build.
P.S. I zipped the folder for attaching.

Original comment by alex....@gmail.com on 10 Jan 2013 at 12:55

Attachments:

• 6.ZIP
• log.txt