Gradle-play-publisher: Mapping file upload fails with error "invalidSymbolFile"

[knordbo]

Describe the bug

When releasing a bundle it fails during upload of deobfuscation files https://developers.google.com/android-publisher/api-ref/edits/deobfuscationfiles/upload

It fails while hitting:
https://www.googleapis.com/upload/androidpublisher/v3/applications/.../deobfuscationFiles

{
 "error": {
  "errors": [
   {
    "domain": "androidpublisher",
    "reason": "invalidSymbolFile",
    "message": "Symbol file invalid."
   }
  ],
  "code": 403,
  "message": "Symbol file invalid."
 }
}

Unsure if this is a problem with Google APIs or the plugin.

Leaving out rest of logs since its all auth headers etc, but it should be easy enough to reproduce.

To Reproduce

./gradlew publishRelease --info

release {
    minifyEnabled true
    proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}

play {
    defaultToAppBundles = true
    serviceAccountCredentials = file("service-account.json")
    track = 'internal'
}

Versions

• Gradle Play Publisher: current master
• Gradle Wrapper (if applicable): 4.7
• Android Gradle Plugin (if applicable): 3.2.0-beta01

Expected behavior

Mapping file successfully uploaded

Additional context

In my case I actually have -dontobfuscate so the mapping file is not needed, maybe it should be configurable? Probably that is overkill though, it never hurts to upload it.

[SUPERCILEX]

Interesting, do both publishBundle and publishApk have this problem? It shouldn't be specific to bundles since the code is shared.

[knordbo]

Yes, it appears to happen in both cases. If there was no actual changes when it was made common between apk and bundle it might indicate either an error/breaking change on Googles side.

[SUPERCILEX]

Nice, that means the bundles PR can move forward. 👍 And yeah, there weren't any changes to mapping stuff when adding bundle support.

I'm able to upload mapping files just fine, but I haven't tried the don't obfuscate stuff so I'll see what happens with that when I take a look tomorrow.

[knordbo]

Yup. I'm not even sure why a mapping file is generated since I use -dontobfuscate

It could very well be a bug in the tooling since I'm on beta02

[knordbo]

When -dontobfuscate is used it generates an empty mapping.txt file. I feel like that is a bug in the tooling, do you want me to create a bug in the google issue tracker instead? Either they should not create an empty file or the endpoint that takes obfuscation files should handle the case for empty file.

As a workaround for now you could check if the file length is 0. The easiest might be to make that change directly in the app-bundle branch to avoid conflict.

[SUPERCILEX]

Can confirm -dontobfuscate breaks it, will fix.

[SUPERCILEX]

@knordbo Yeah, feel free to file a bug if you'd like. 👍 (It might take a while to get fixed though because the AGP team will have to file the bug with GuardSquare and wait for them to fix it.)

[knordbo]

Apparently been reported for a while: https://issuetracker.google.com/issues/74257813
Make sure to upvote.

[SUPERCILEX]

@knordbo Thanks for finding that, starred!

[dlew]

It's looking like AGP 3.2 might go out with the empty mapping files still being generated. Could we reopen this and look into the possibility of simply ignoring empty mapping files on upload?

[SUPERCILEX]

@dlew yup, we already fixed it on our end: https://github.com/Triple-T/gradle-play-publisher/pull/370

[dlew]

Oh nice, great!

Any idea on when 2.0.0 will be released? (Just trying to figure out how we should proceed - if we should focus on a workaround or just wait for 2.0.0.)

[SUPERCILEX]

@dlew I don't have the keys to master, so that's up to @bhurling. In the meantime, there are snapshot builds available or you can get a static JitPack artifact: com.github.Triple-T:gradle-play-publisher:860be50bec.