Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PlatformBuildVersion information changes unexpectedly #1909

Closed
gino247 opened this issue Sep 28, 2018 · 24 comments · Fixed by #1960

Comments

@gino247
Copy link

commented Sep 28, 2018

Information

  1. Apktool Version (apktool -version) 2.3.4 -
  2. Operating System (Mac, Linux, Windows) Mac 10.13 -
  3. APK From? (Playstore, ROM, Other) Own -

Steps to Reproduce

  1. Delete all previous frameworks
  2. Decompile apk, get Manifest with the following
    platformBuildVersionCode="27" platformBuildVersionName="8.1.0"
  3. Recompile apk, then decompile again, and the Manifest contains the following
    platformBuildVersionCode="23" platformBuildVersionName="6.0-2438415"

So now playstore is rejecting the apk.
What am I missing or is this a real issue?

Questions to ask before submission

  1. Have you tried apktool d, apktool b without changing anything? yes
  2. If you are trying to install a modified apk, did you resign it? N/A
  3. Are you using the latest apktool version? yes
@iBotPeaches

This comment has been minimized.

Copy link
Owner

commented Sep 28, 2018

So the aapt internal to Apktool, I imagine has those properties. Our best solution in this case is to not touch those properties.

@iBotPeaches iBotPeaches added the Bug label Sep 28, 2018

@gino247

This comment has been minimized.

Copy link
Author

commented Sep 28, 2018

Hi,
Thanks for quick response.
Any chances I can get to the source of the internal aapt?

@iBotPeaches

This comment has been minimized.

@gino247

This comment has been minimized.

Copy link
Author

commented Oct 2, 2018

Hi
Any guides on how to build this using a mac OS?

@gino247

This comment has been minimized.

Copy link
Author

commented Oct 2, 2018

Thanks,
While waiting for the repo to download.
For the aapt tool I found in Resource.cpp extractPlatformBuildVersion is the only place that setPlatformBuildVersion is called.
Is this value not pulled from the framework apk?
I am not sure how the useCompileSdkVersion is set though.

@iBotPeaches

This comment has been minimized.

Copy link
Owner

commented Oct 2, 2018

@gino247 Not in my understanding, the platform is the version that is built. Frameworks have nothing to do with that. Apktool introduced the notion of frameworks so it could keep resources from OEMs / other versions, instead of referring to the internal SDK set of resources. It would be a patch to send those versions to aapt so it can include that version information - which is too much work.

The real fix is to prevent clobbering those fields and keep them unchanged.

@gino247

This comment has been minimized.

Copy link
Author

commented Oct 9, 2018

Hi,

Finally managed to get a build working on a mac.
FYI: Had to edit build/soong/cc/config/x86_darwin_host.go to include the lastest sdk 10.14

Any how added the following to Resource.cpp:

   //Extract platformBuild info from current AndroidManifest.xml
    ssize_t platformBuildVersionCodeIndex = block.indexOfAttribute(NULL, "platformBuildVersionCode");
    if (platformBuildVersionCodeIndex >= 0) {
      const char16_t* platformBuildVersionCode16 = block.getAttributeStringValue(platformBuildVersionCodeIndex, &len);
      bundle->setPlatformBuildVersionCode(String8(platformBuildVersionCode16));
    }

    ssize_t platformBuildVersionNameIndex = block.indexOfAttribute(NULL, "platformBuildVersionName");
    if (platformBuildVersionNameIndex >= 0) {
      const char16_t* platformBuildVersionName16 = block.getAttributeStringValue(platformBuildVersionNameIndex, &len);
      bundle->setPlatformBuildVersionName(String8(platformBuildVersionName16));
    }

Inside function
static status_t parsePackage(Bundle* bundle, const sp<AaptAssets>& assets, const sp<AaptGroup>& grp)
just above this line:
String16 uses_sdk16("uses-sdk");

A quick test seems to generate the right out. Also if the values are not set in bundle then it gets pulled from the framework (1.apk) apk.

So if these changes are ok, what is next to get it a fix released?

Regards,

@gino247

This comment has been minimized.

Copy link
Author

commented Oct 9, 2018

Forgot to mention I only made the changes on aapt not aapt2. As that just fails.

@gino247

This comment has been minimized.

Copy link
Author

commented Oct 10, 2018

Hi,

If you need me to push these changes via git then I can also do so, might just need access then.

Regards,

@iBotPeaches

This comment has been minimized.

Copy link
Owner

commented Oct 10, 2018

Hi,

You are welcome to "fork" the frameworks_base repo I have and make a pull request. I can't currently accept the PR unless both aapt2/aapt1 have the feature. If you submit just aapt1, I'll have to spend some time creating a patch for aapt2.

After we review the patches, then it'll be merged in and be in the next release.

@gino247

This comment has been minimized.

Copy link
Author

commented Oct 12, 2018

Hi,

Ok. I will see if I can find the spot in aapt2, but I have no way of testing aapt2 since it just fails without any changes.
I'll fork and create a pull request.

Regards,

@gino247

This comment has been minimized.

Copy link
Author

commented Oct 13, 2018

Hi,
I have tried to just use aapt2 to build the apk from decompilation, but it fails with the following error:
tools/apktool/Build-2.6.2-1/res/values/ids.xml:19: error: <item> inner element must either be a resource reference or empty.
but it build without issues using aapt.

Any ideas?

Regards,

@gino247

This comment has been minimized.

Copy link
Author

commented Oct 14, 2018

Hi,
Ok after editing the ids.xml, no idea why there is a false in some fields though, I managed to build using default aapt2 and the build looks good.

I have forked and created a pull request.

Regards,

@gino247

This comment has been minimized.

Copy link
Author

commented Oct 16, 2018

Hi,

Ok I have forked and made changes on my side.
I have not done this before so I created a pull request for 2 issues, one on this issue gino247-patch-1 and one on apktool for issue 1918 also.
Please check and educate me if need be.

Regards,

@iBotPeaches

This comment has been minimized.

Copy link
Owner

commented Oct 16, 2018

@gino247 I don't see any pull-requests.

Confirm you are using

To submit pull-requests.

@gino247

This comment has been minimized.

Copy link
Author

commented Oct 16, 2018

My bad it should be there now.

@iBotPeaches iBotPeaches added this to the 2.4.0 milestone Nov 1, 2018

@prabhu-bsft

This comment has been minimized.

Copy link

commented Dec 3, 2018

Hi @gino247 @iBotPeaches,

Is it possible to get a version of apktool with this fix? Or is the only option to compile it ourself? Thanks in advance!

@mkilling

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2018

Thanks! We’re currently also trying to compile ourselves to get a version with this fix. Would be extremely handy if a release could be provided.

@gino247

This comment has been minimized.

Copy link
Author

commented Dec 5, 2018

Hi,

@prabhu-bsft , @mkilling
A workaround for now would be to use aapt2 switch when building, but you'll need to remove the false/true statements in the ids.xml file before building.

e.g. (Linux)

sed 's/true//g' <path>/ids.xml
sed 's/false//g' <path>/ids.xml
./apktool.sh b --use-aapt2 <folder>

Hope this helps, till the next release.

@prabhu-bsft

This comment has been minimized.

Copy link

commented Dec 5, 2018

@gino247 Thanks a lot. I will try it out.

@bingqiao

This comment has been minimized.

Copy link
Contributor

commented Dec 10, 2018

Rebuilding with appt2 fixes PlatformBuildVersionName but I still get: android:compileSdkVersionCodename="6.0-2438415"

Not sure if this can be deployed to play store. Will have to try later.

I suppose both android:compileSdkVersion and android:compileSdkVersionCodename come from framework so don't really matter?

Will deploy it to play store later.

@iBotPeaches

This comment has been minimized.

Copy link
Owner

commented Dec 18, 2018

Hiya folks. I've looped back to this ticket after clearing a backlog of tasks. I've merged the fix for aapt1 in regards to inheriting platform* values during build. This fix is only in aapt1 as of now. Patching this same change for v2 is under investigation, but anyone can help with that stage.

My low level AOSP knowledge, especially in regards to C++ is not good so it will take me effort to patch aapt2 for this change.

The patch for aapt1 if anyone is interested in contributing the aapt2 patch - iBotPeaches/platform_frameworks_base@4b10686#diff-e7a93bfac1c422acb7946f9512eb2712

@iBotPeaches iBotPeaches self-assigned this Dec 18, 2018

@iBotPeaches iBotPeaches pinned this issue Dec 18, 2018

@iBotPeaches

This comment has been minimized.

Copy link
Owner

commented Jan 4, 2019

Okay, so this is good to go. aapt1 has been patched to act the same way aapt2 does. I confirmed this by building an application in Android Studio, then decoding it and rebuilding it both aapt1/aapt2.

I compared the output of aapt d xmltree app.apk AndroidManifest.xml and diffed it. There were no changes for the platformBuildVersionCode and platformBuildVersionName fields.

There is regression for the compileSdkVersion & compileSdkVersionCodename but still digging if effort needs to be taken to match those properties to the original, which might even be null (as they sometimes won't exist)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.