Possible sharedLibrary issue #936

Closed
xdabbeb opened this Issue May 4, 2015 · 6 comments

Comments

Projects
None yet
2 participants
@xdabbeb

xdabbeb commented May 4, 2015

Issue with current release (2.0.0) and personal snapshot (1fb87e) builds and certain apks on recent LG LP firmware. It seems to be related to related to the recent sharedLibrary implementation.

Test case files:
https://www.dropbox.com/s/zpd81okew0zhr9m/apktool_bug_test_files.zip?dl=0

Steps to reproduce:

  1. add resources
    apktool if lge-res.apk
    apktool if framework-res.apk
  2. decompile
    apktool d LGLockScreenSettings.apk
  3. recompile
    apktool b -c LGLockScreenSettings

This recompiled apk (with no modifications) will produce errors such as the following when the resources are requested:
http://pastebin.com/HF0iPvzc

I've been getting around this so far by removing the sharedLibrary tag from apktool.yml and forcing aapt to the 19.1.0 release, but that is obviously less than ideal. I have verified that the pkg id of the test apk is 0x7f as expected. I would suspect it's adding that tag because it needs lge-res.apk (which is a sharedLibrary)? I haven't looked into it further at this point. Thanks again for this wonderful tool!

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches May 4, 2015

Owner

sharedLibrary is only thrown true in apktool.yml if the file has a pkgId of 0. You can see this here -

What I failed to realize is that this function runs for all apks, frameworks and the apk alike. This means since the real shared framework (lge-res) is ran, it throws this thus causing the boolean to be true. This should be an easy fix.

I don't know why you are using a different aapt though. Based on my research, the correct fix would be to not use --shared-lib which would fix the problem. Is there any reason you chose to use to use your own aapt binary?

Owner

iBotPeaches commented May 4, 2015

sharedLibrary is only thrown true in apktool.yml if the file has a pkgId of 0. You can see this here -

What I failed to realize is that this function runs for all apks, frameworks and the apk alike. This means since the real shared framework (lge-res) is ran, it throws this thus causing the boolean to be true. This should be an easy fix.

I don't know why you are using a different aapt though. Based on my research, the correct fix would be to not use --shared-lib which would fix the problem. Is there any reason you chose to use to use your own aapt binary?

@iBotPeaches iBotPeaches added this to the v2.0.1 milestone May 4, 2015

@xdabbeb

This comment has been minimized.

Show comment
Hide comment
@xdabbeb

xdabbeb May 4, 2015

That was my understanding from browsing the source as well (that it would only tag sharedLibrary if when it found pkg id 0), but I verified using aapt and just opening resources.arsc in a hex editor that this package has an id of 0x7f, so I figured that it was running against all as well.

I force it to the 19.1.0 aapt because after removing the sharedLibrary tag, building it with the internal (or any 21+ aapt) will fail. Using internal I get a series of errors such as:

W/ResourceType(15641): Entry identifier 0x3 is larger than entry count 0x2

and

LGLockScreenSettings/res/layout/checkview_layout.xml:4: error: Error: No resource found that matches the given name (at 'id' with value '@id/linearLayout1').

xdabbeb commented May 4, 2015

That was my understanding from browsing the source as well (that it would only tag sharedLibrary if when it found pkg id 0), but I verified using aapt and just opening resources.arsc in a hex editor that this package has an id of 0x7f, so I figured that it was running against all as well.

I force it to the 19.1.0 aapt because after removing the sharedLibrary tag, building it with the internal (or any 21+ aapt) will fail. Using internal I get a series of errors such as:

W/ResourceType(15641): Entry identifier 0x3 is larger than entry count 0x2

and

LGLockScreenSettings/res/layout/checkview_layout.xml:4: error: Error: No resource found that matches the given name (at 'id' with value '@id/linearLayout1').

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches May 4, 2015

Owner

Okay,

I don't blame you on that. Ever since aapt was refactored it has had quite the amount of bugs. I think apktool's internal aapt is up to date with master of AOSP, but I'll double check. Maybe there are some bug fixes for that. I can promise a fix for the improper sharedLibrary, but as for the broken aapt, that is upstream.

Owner

iBotPeaches commented May 4, 2015

Okay,

I don't blame you on that. Ever since aapt was refactored it has had quite the amount of bugs. I think apktool's internal aapt is up to date with master of AOSP, but I'll double check. Maybe there are some bug fixes for that. I can promise a fix for the improper sharedLibrary, but as for the broken aapt, that is upstream.

@xdabbeb

This comment has been minimized.

Show comment
Hide comment
@xdabbeb

xdabbeb May 4, 2015

No worries at all...and, yeah, I've noticed it has been a bit of a mess. I had a few issues with a project in AS a while back that made me keep the 19.1.0 aapt around so it's no problem for things like this. If there's anything else I can provide/test, feel free to ask. Thanks again for everything.

xdabbeb commented May 4, 2015

No worries at all...and, yeah, I've noticed it has been a bit of a mess. I had a few issues with a project in AS a while back that made me keep the 19.1.0 aapt around so it's no problem for things like this. If there's anything else I can provide/test, feel free to ask. Thanks again for everything.

iBotPeaches added a commit that referenced this issue May 5, 2015

Prevent frameworks from modifying sharedLibrary
Since all frameworks are decoded the same via readPackage(), reading
a framework that was a sharedLibrary would throw the sharedLibrary
flag for the apk. Since packageName isn't set until after the first
decode, we check the values to make sure we only set this variable on
the first apk decoded. Refs #936
@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches May 5, 2015

Owner

As linked above a change has been pushed for the incorrect setting of sharedLibrary - 48285bd

I checked out AOSP to look for updates.

Apktool latest commit is de3ab0a9e8609f6a631b2c047f352069bb9cfa86

AOSP has had 7 commits to aapt since then, as shown here - https://github.com/android/platform_frameworks_base/commits/master/tools/aapt

All these commits look like code cleanup and nothing related to bug fixes.

Owner

iBotPeaches commented May 5, 2015

As linked above a change has been pushed for the incorrect setting of sharedLibrary - 48285bd

I checked out AOSP to look for updates.

Apktool latest commit is de3ab0a9e8609f6a631b2c047f352069bb9cfa86

AOSP has had 7 commits to aapt since then, as shown here - https://github.com/android/platform_frameworks_base/commits/master/tools/aapt

All these commits look like code cleanup and nothing related to bug fixes.

@iBotPeaches

This comment has been minimized.

Show comment
Hide comment
@iBotPeaches

iBotPeaches May 5, 2015

Owner

Since I fixed the issue in apktool. The busted aapt is being tracked here - #857

It shows the failure with new aapt. The other fix is merged mainline, therefore closing this.

Thanks for report!

Owner

iBotPeaches commented May 5, 2015

Since I fixed the issue in apktool. The busted aapt is being tracked here - #857

It shows the failure with new aapt. The other fix is merged mainline, therefore closing this.

Thanks for report!

@iBotPeaches iBotPeaches closed this May 5, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment