How to send android mapping.txt manually?

[ghost]

Hi there, may I ask how to send android generated mapping.txt manually? or I can only send the mapping through build time?

[pjq]

Does the code still maintain by Flurry?

And I have the same question.

[clayreimann]

@pjq it is still maintained.

@qliu-pdftron you could potentially make the same sequence of http calls that the plugin does (it's all done here). But you'll also need to set the same uuid property in your android app that we do (again see the plugin code) and you should be aware that this is not a documented API so is subject to change at any time.

[pjq]

@clayreimann So we don't have the console to upload the mapping. Can we suggest to add this feature? If you use Google Play console, it support manually upload the mapping in the console.

[clayreimann]

I don’t know what you mean by console to upload the mapping. What about the Gradle plugin as it currently is does not suit your needs?

_{Sent with GitHawk}

[pjq]

@clayreimann I mean it can do in the website, just with one click to upload the file.

Yes, for the already released version we have not integrate your plugins, but we have the local mapping file.

[pjq]

@qliu-pdftron @clayreimann FYI. I just build one tool to support manually upload the mapping file

./upload.sh mapping.txt

Github: https://github.com/pjq/FlurryUploadAndroidMapping

[clayreimann]

@pjq I appreciate your enthusaism for our crash product, however at this time we do not support uploading mapping.txt files for specific versions or builds. We do not currently symbolicate Android apps built with Flurry SDK before 6.7.0 or built that were built without using the gradle plugin. See the documentation for symbolication requirements.

The gradle plugin does some required configuration in your app (see the code I referenced in an earlier comment). You could duplicate that code in your own builds if you really want to, and then you can use proguard-upload-1.1.0-all.jar as a command-line client to our API for builds that have this configuration. It would really be easier if you just use the plugin though.

[pjq]

@clayreimann I see, yes, I am aware of that the mapping file just work for the new version and also doesn't work for the already occurred crash log.

And for the code, can you correct me which logic is missing? https://github.com/pjq/FlurryUploadAndroidMapping/blob/master/src/main/java/me/pjq/flurry/FlurryMappingUploadTools.java

And for the build, we need to build different Android versions, how to config different API/Token in your gradle plugin? Do you have any example?

[pjq]

@clayreimann And I have another question. For the release build, it will upload the mapping file automatically by the plugin. So if we have 10 developers, and all of them will build the release version locally, so what will happen to the mapping file? The last one is correct? And the new one will override the old one?

[clayreimann]

@pjq it's not that there is missing logic to upload files (since you're just using the same code that we do for uploading files), however the files that you upload will not be used to symbolicate crashes. To understand why let me answer another of your questions.

So if we have 10 developers, and all of them will build the release version locally, so what will happen to the mapping file? The last one is correct? And the new one will override the old one?

Each mapping file will be correct for each build of the app. The sdk sends the value of the resource configured here https://github.com/flurry/upload-clients/blob/0bb83f1fbbe936fdadbda102ff95a16632fccf0c/gradle/src/main/groovy/com/flurry/android/symbols/SymbolUploadPlugin.groovy#L48 We use that uuid in our processing systems to determine what mapping.txt file matches a particular build. This is why we do not currently support sending mapping.txt files for builds before SDK 6.7.0 or builds that did not use our gradle plugin.

I'm not exactly sure what you mean by this.

And for the build, we need to build different Android versions, how to config different API/Token in your gradle plugin?

However, if you're referring to free/paid or testing/production or some other split you can always put some logic in your build.gradle to change things based on a build flag. e.g.

String buildType = project.hasProperty('freeBuild') ? 'free' : 'paid'
flurryCrash {
  configPath buildType == 'free' ? 'free.config' : 'paid.config'
}

you can toggle this by gradle build -PfreeBuild

[pjq]

@clayreimann Thanks for your detailed explanation. So for the mapping, the plugin will generate the UUID and it will shipped with the APK to identify which build is matched. That's make sense.

And for the new build >= SDK 6.7.0, if I still not integrate the plugin, so if need to support upload mapping file manually, does it means I need to get the correct UUID that generated in the build process? And how?

For the last question, yes, that's what I want, thanks so much.

[pjq]

I follow the guide, and integrate the plugin It occur some errors, and break the release build. Is it possible to not block the build? We don't want the plugin error block the build.

 Task :app:assembleA_googleplayRelease FAILED
IO Exception during request: POST https://upload.flurry.com/upload/v1/upload/11412xx/xx2267 HTTP/1.1
org.apache.http.conn.ConnectionPoolTimeoutException: Timeout waiting for connection from pool
        at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.leaseConnection(PoolingHttpClientConnectionManager.java:286)
        at org.apache.http.impl.conn.PoolingHttpClientConnectionManager$1.get(PoolingHttpClientConnectionManager.java:263)
        at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:190)
        at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
        at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
        at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
        at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
        at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
        at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
        at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
        at com.flurry.proguard.UploadProGuardMapping.executeHttpRequest(UploadProGuardMapping.java:362)
        at com.flurry.proguard.UploadProGuardMapping.sendToUploadService(UploadProGuardMapping.java:271)
        at com.flurry.proguard.UploadProGuardMapping.uploadFile(UploadProGuardMapping.java:140)
        at com.flurry.proguard.UploadProGuardMapping$uploadFile.call(Unknown Source)

[mmarczell-graphisoft]

@clayreimann The current version of the plugin does not set any property in the build as far as I can see. Line 48 of SymbolUploadPlugin.groovy used to, but now there is just a logging message. It was removed in a7bd532.

Can you explain why that is? Is that a regression? How should we configure our build for manual symbol upload based on the current plugin source?

[clayreimann]

@suriyasundar92 can you look into this

[suriyasundar92]

@mmarczell-graphisoft Ill look into the issue.

[suriyasundar92]

@mmarczell-graphisoft Thanks for bringing this to our notice. I have fixed the issue. Please use the latest version(3.1.2) so that the uuid's are set properly.