Apktool: PlatformBuildVersion information changes unexpectedly

[gino247]

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]

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

[gino247]

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

[iBotPeaches]

https://github.com/iBotPeaches/platform_frameworks_base

[gino247]

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

[iBotPeaches]

https://github.com/iBotPeaches/Apktool/blob/master/INTERNAL.md#building-the-aapt2-binary

[gino247]

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]

@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]

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]

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

[gino247]

Hi,

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

Regards,

[iBotPeaches]

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]

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]

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]

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]

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]

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

Confirm you are using

• https://github.com/iBotPeaches/platform_frameworks_base
• https://github.com/iBotPeaches/Apktool

To submit pull-requests.

[gino247]

My bad it should be there now.

[prabhu-bsft]

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]

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]

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]

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

[bingqiao]

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]

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 - https://github.com/iBotPeaches/platform_frameworks_base/commit/4b1068628a94f8266460406314faed020bf84a66#diff-e7a93bfac1c422acb7946f9512eb2712

[iBotPeaches]

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)