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
Closed

PlatformBuildVersion information changes unexpectedly #1909

gino247 opened this issue Sep 28, 2018 · 24 comments · Fixed by #1960
Assignees
Labels
Milestone

Comments

@gino247
Copy link

gino247 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
Copy link
Owner

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

@gino247
Copy link
Author

gino247 commented Sep 28, 2018

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

@iBotPeaches
Copy link
Owner

@gino247
Copy link
Author

gino247 commented Oct 2, 2018

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

@gino247
Copy link
Author

gino247 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
Copy link
Owner

@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
Copy link
Author

gino247 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
Copy link
Author

gino247 commented Oct 9, 2018

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

@gino247
Copy link
Author

gino247 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
Copy link
Owner

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
Copy link
Author

gino247 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
Copy link
Author

gino247 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
Copy link
Author

gino247 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
Copy link
Author

gino247 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
Copy link
Owner

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

Confirm you are using

To submit pull-requests.

@gino247
Copy link
Author

gino247 commented Oct 16, 2018

My bad it should be there now.

@prabhu-bsft
Copy link

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
Copy link
Contributor

mkilling 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
Copy link
Author

gino247 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
Copy link

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

@bingqiao
Copy link
Contributor

bingqiao 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
Copy link
Owner

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
Copy link
Owner

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
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants