Crashlytics not uploading mapping file
up vote
0
down vote
favorite
I'm able to see crashes for a release build in Crashlytics but they are still obfuscated. I'm using:
implementation "com.google.firebase:firebase-core:16.0.5"
implementation "com.google.android.gms:play-services-base:16.0.1"
implementation "com.crashlytics.sdk.android:crashlytics:2.9.6"
and (project level)
classpath 'com.android.tools.build:gradle:3.2.1'
classpath 'com.google.gms:google-services:4.2.0'
classpath 'io.fabric.tools:gradle:1.26.1' // Crashlytics plugin
classpath "net.ltgt.gradle:gradle-apt-plugin:0.15"
I've followed the instructions at https://firebase.google.com/docs/crashlytics/get-deobfuscated-report, in particular I've deleted the -printmapping <path>/mapping.txt
line from config.txt
When I look in the Crashlytics log I do not see an upload of the mapping file.
When I run a release build for an earlier version of my project using:
implementation "com.google.firebase:firebase-core:11.8.0"
implementation "com.google.android.gms:play-services-base:11.8.0"
implementation('com.crashlytics.sdk.android:crashlytics:2.8.0@aar') {
transitive = true
}
and (project level)
classpath 'com.android.tools.build:gradle:3.1.3'
classpath 'com.google.gms:google-services:3.0.0'
classpath 'io.fabric.tools:gradle:1.24.4'
then I see unobfuscated stack traces and mapping upload messages in crashlytics.log:
2018-11-21 10:52:22.573 [DEBUG] (Daemon worker) com.crashlytics - Deobfuscation file(s) uploaded.
Any ideas what's wrong? I don't see any of the mapping file related logs for the recent (not working) version in the Crashlytics log and I don't see the gradle upload task running in the gradle output whereas for the older (working) version I see the following:
:app:crashlyticsUploadDeobsRelease (Thread[Daemon worker Thread 2,5,main]) completed. Took 1.28 secs.
android crashlytics crashlytics-android
add a comment |
up vote
0
down vote
favorite
I'm able to see crashes for a release build in Crashlytics but they are still obfuscated. I'm using:
implementation "com.google.firebase:firebase-core:16.0.5"
implementation "com.google.android.gms:play-services-base:16.0.1"
implementation "com.crashlytics.sdk.android:crashlytics:2.9.6"
and (project level)
classpath 'com.android.tools.build:gradle:3.2.1'
classpath 'com.google.gms:google-services:4.2.0'
classpath 'io.fabric.tools:gradle:1.26.1' // Crashlytics plugin
classpath "net.ltgt.gradle:gradle-apt-plugin:0.15"
I've followed the instructions at https://firebase.google.com/docs/crashlytics/get-deobfuscated-report, in particular I've deleted the -printmapping <path>/mapping.txt
line from config.txt
When I look in the Crashlytics log I do not see an upload of the mapping file.
When I run a release build for an earlier version of my project using:
implementation "com.google.firebase:firebase-core:11.8.0"
implementation "com.google.android.gms:play-services-base:11.8.0"
implementation('com.crashlytics.sdk.android:crashlytics:2.8.0@aar') {
transitive = true
}
and (project level)
classpath 'com.android.tools.build:gradle:3.1.3'
classpath 'com.google.gms:google-services:3.0.0'
classpath 'io.fabric.tools:gradle:1.24.4'
then I see unobfuscated stack traces and mapping upload messages in crashlytics.log:
2018-11-21 10:52:22.573 [DEBUG] (Daemon worker) com.crashlytics - Deobfuscation file(s) uploaded.
Any ideas what's wrong? I don't see any of the mapping file related logs for the recent (not working) version in the Crashlytics log and I don't see the gradle upload task running in the gradle output whereas for the older (working) version I see the following:
:app:crashlyticsUploadDeobsRelease (Thread[Daemon worker Thread 2,5,main]) completed. Took 1.28 secs.
android crashlytics crashlytics-android
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I'm able to see crashes for a release build in Crashlytics but they are still obfuscated. I'm using:
implementation "com.google.firebase:firebase-core:16.0.5"
implementation "com.google.android.gms:play-services-base:16.0.1"
implementation "com.crashlytics.sdk.android:crashlytics:2.9.6"
and (project level)
classpath 'com.android.tools.build:gradle:3.2.1'
classpath 'com.google.gms:google-services:4.2.0'
classpath 'io.fabric.tools:gradle:1.26.1' // Crashlytics plugin
classpath "net.ltgt.gradle:gradle-apt-plugin:0.15"
I've followed the instructions at https://firebase.google.com/docs/crashlytics/get-deobfuscated-report, in particular I've deleted the -printmapping <path>/mapping.txt
line from config.txt
When I look in the Crashlytics log I do not see an upload of the mapping file.
When I run a release build for an earlier version of my project using:
implementation "com.google.firebase:firebase-core:11.8.0"
implementation "com.google.android.gms:play-services-base:11.8.0"
implementation('com.crashlytics.sdk.android:crashlytics:2.8.0@aar') {
transitive = true
}
and (project level)
classpath 'com.android.tools.build:gradle:3.1.3'
classpath 'com.google.gms:google-services:3.0.0'
classpath 'io.fabric.tools:gradle:1.24.4'
then I see unobfuscated stack traces and mapping upload messages in crashlytics.log:
2018-11-21 10:52:22.573 [DEBUG] (Daemon worker) com.crashlytics - Deobfuscation file(s) uploaded.
Any ideas what's wrong? I don't see any of the mapping file related logs for the recent (not working) version in the Crashlytics log and I don't see the gradle upload task running in the gradle output whereas for the older (working) version I see the following:
:app:crashlyticsUploadDeobsRelease (Thread[Daemon worker Thread 2,5,main]) completed. Took 1.28 secs.
android crashlytics crashlytics-android
I'm able to see crashes for a release build in Crashlytics but they are still obfuscated. I'm using:
implementation "com.google.firebase:firebase-core:16.0.5"
implementation "com.google.android.gms:play-services-base:16.0.1"
implementation "com.crashlytics.sdk.android:crashlytics:2.9.6"
and (project level)
classpath 'com.android.tools.build:gradle:3.2.1'
classpath 'com.google.gms:google-services:4.2.0'
classpath 'io.fabric.tools:gradle:1.26.1' // Crashlytics plugin
classpath "net.ltgt.gradle:gradle-apt-plugin:0.15"
I've followed the instructions at https://firebase.google.com/docs/crashlytics/get-deobfuscated-report, in particular I've deleted the -printmapping <path>/mapping.txt
line from config.txt
When I look in the Crashlytics log I do not see an upload of the mapping file.
When I run a release build for an earlier version of my project using:
implementation "com.google.firebase:firebase-core:11.8.0"
implementation "com.google.android.gms:play-services-base:11.8.0"
implementation('com.crashlytics.sdk.android:crashlytics:2.8.0@aar') {
transitive = true
}
and (project level)
classpath 'com.android.tools.build:gradle:3.1.3'
classpath 'com.google.gms:google-services:3.0.0'
classpath 'io.fabric.tools:gradle:1.24.4'
then I see unobfuscated stack traces and mapping upload messages in crashlytics.log:
2018-11-21 10:52:22.573 [DEBUG] (Daemon worker) com.crashlytics - Deobfuscation file(s) uploaded.
Any ideas what's wrong? I don't see any of the mapping file related logs for the recent (not working) version in the Crashlytics log and I don't see the gradle upload task running in the gradle output whereas for the older (working) version I see the following:
:app:crashlyticsUploadDeobsRelease (Thread[Daemon worker Thread 2,5,main]) completed. Took 1.28 secs.
android crashlytics crashlytics-android
android crashlytics crashlytics-android
edited 12 hours ago
asked Nov 21 at 21:34
Ewan
78111
78111
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
Have you read here: https://docs.fabric.io/android/crashlytics/dex-and-proguard.html ?
I'm using those lines in my proguard-rules.pro
file (inside your app folder) to get de-obfuscated crash reports
-keepattributes *Annotation*
-keepattributes SourceFile,LineNumberTable
# prevent Crashlytics obfuscation
-keep class com.crashlytics.** { *; }
-dontwarn com.crashlytics.**
And be sure to not have this line in your proguard file
-printmapping mapping.txt
Thanks, yes I do have those lines inproguard-rules.pro
and I don't have (indeed have never had)-printmapping mapping.txt
. I did have a lingeringconfig.txt
file ( from earlier vn?) which had it and I deleted, to no effect. Now I have removedconfig.txt
. I'm interested to see if others seeDeobfuscation file(s) uploaded.
in their crashlytics logs....
– Ewan
Nov 21 at 22:15
Where are you initializing Crashlytics? In a customApplication
class?
– MatPag
Nov 21 at 22:18
Yes (but don't think it's needed now). Crashlytics is working in that it's sending the stack trace. The problem is the stack trace is obfuscated. If you search foruploaded
in your crashlytics log you should see the upload logged. That's what's not happening for me. Make sense? On Linux / Windows: ~/.crashlytics/com.crashlytics.tools/crashlytics.log On Mac: ~/Library/Caches/com.crashlytics/com.crashlytics.tools/crashlytics.log
– Ewan
Nov 22 at 9:15
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
Have you read here: https://docs.fabric.io/android/crashlytics/dex-and-proguard.html ?
I'm using those lines in my proguard-rules.pro
file (inside your app folder) to get de-obfuscated crash reports
-keepattributes *Annotation*
-keepattributes SourceFile,LineNumberTable
# prevent Crashlytics obfuscation
-keep class com.crashlytics.** { *; }
-dontwarn com.crashlytics.**
And be sure to not have this line in your proguard file
-printmapping mapping.txt
Thanks, yes I do have those lines inproguard-rules.pro
and I don't have (indeed have never had)-printmapping mapping.txt
. I did have a lingeringconfig.txt
file ( from earlier vn?) which had it and I deleted, to no effect. Now I have removedconfig.txt
. I'm interested to see if others seeDeobfuscation file(s) uploaded.
in their crashlytics logs....
– Ewan
Nov 21 at 22:15
Where are you initializing Crashlytics? In a customApplication
class?
– MatPag
Nov 21 at 22:18
Yes (but don't think it's needed now). Crashlytics is working in that it's sending the stack trace. The problem is the stack trace is obfuscated. If you search foruploaded
in your crashlytics log you should see the upload logged. That's what's not happening for me. Make sense? On Linux / Windows: ~/.crashlytics/com.crashlytics.tools/crashlytics.log On Mac: ~/Library/Caches/com.crashlytics/com.crashlytics.tools/crashlytics.log
– Ewan
Nov 22 at 9:15
add a comment |
up vote
1
down vote
Have you read here: https://docs.fabric.io/android/crashlytics/dex-and-proguard.html ?
I'm using those lines in my proguard-rules.pro
file (inside your app folder) to get de-obfuscated crash reports
-keepattributes *Annotation*
-keepattributes SourceFile,LineNumberTable
# prevent Crashlytics obfuscation
-keep class com.crashlytics.** { *; }
-dontwarn com.crashlytics.**
And be sure to not have this line in your proguard file
-printmapping mapping.txt
Thanks, yes I do have those lines inproguard-rules.pro
and I don't have (indeed have never had)-printmapping mapping.txt
. I did have a lingeringconfig.txt
file ( from earlier vn?) which had it and I deleted, to no effect. Now I have removedconfig.txt
. I'm interested to see if others seeDeobfuscation file(s) uploaded.
in their crashlytics logs....
– Ewan
Nov 21 at 22:15
Where are you initializing Crashlytics? In a customApplication
class?
– MatPag
Nov 21 at 22:18
Yes (but don't think it's needed now). Crashlytics is working in that it's sending the stack trace. The problem is the stack trace is obfuscated. If you search foruploaded
in your crashlytics log you should see the upload logged. That's what's not happening for me. Make sense? On Linux / Windows: ~/.crashlytics/com.crashlytics.tools/crashlytics.log On Mac: ~/Library/Caches/com.crashlytics/com.crashlytics.tools/crashlytics.log
– Ewan
Nov 22 at 9:15
add a comment |
up vote
1
down vote
up vote
1
down vote
Have you read here: https://docs.fabric.io/android/crashlytics/dex-and-proguard.html ?
I'm using those lines in my proguard-rules.pro
file (inside your app folder) to get de-obfuscated crash reports
-keepattributes *Annotation*
-keepattributes SourceFile,LineNumberTable
# prevent Crashlytics obfuscation
-keep class com.crashlytics.** { *; }
-dontwarn com.crashlytics.**
And be sure to not have this line in your proguard file
-printmapping mapping.txt
Have you read here: https://docs.fabric.io/android/crashlytics/dex-and-proguard.html ?
I'm using those lines in my proguard-rules.pro
file (inside your app folder) to get de-obfuscated crash reports
-keepattributes *Annotation*
-keepattributes SourceFile,LineNumberTable
# prevent Crashlytics obfuscation
-keep class com.crashlytics.** { *; }
-dontwarn com.crashlytics.**
And be sure to not have this line in your proguard file
-printmapping mapping.txt
edited Nov 21 at 22:00
answered Nov 21 at 21:49
MatPag
11.8k63651
11.8k63651
Thanks, yes I do have those lines inproguard-rules.pro
and I don't have (indeed have never had)-printmapping mapping.txt
. I did have a lingeringconfig.txt
file ( from earlier vn?) which had it and I deleted, to no effect. Now I have removedconfig.txt
. I'm interested to see if others seeDeobfuscation file(s) uploaded.
in their crashlytics logs....
– Ewan
Nov 21 at 22:15
Where are you initializing Crashlytics? In a customApplication
class?
– MatPag
Nov 21 at 22:18
Yes (but don't think it's needed now). Crashlytics is working in that it's sending the stack trace. The problem is the stack trace is obfuscated. If you search foruploaded
in your crashlytics log you should see the upload logged. That's what's not happening for me. Make sense? On Linux / Windows: ~/.crashlytics/com.crashlytics.tools/crashlytics.log On Mac: ~/Library/Caches/com.crashlytics/com.crashlytics.tools/crashlytics.log
– Ewan
Nov 22 at 9:15
add a comment |
Thanks, yes I do have those lines inproguard-rules.pro
and I don't have (indeed have never had)-printmapping mapping.txt
. I did have a lingeringconfig.txt
file ( from earlier vn?) which had it and I deleted, to no effect. Now I have removedconfig.txt
. I'm interested to see if others seeDeobfuscation file(s) uploaded.
in their crashlytics logs....
– Ewan
Nov 21 at 22:15
Where are you initializing Crashlytics? In a customApplication
class?
– MatPag
Nov 21 at 22:18
Yes (but don't think it's needed now). Crashlytics is working in that it's sending the stack trace. The problem is the stack trace is obfuscated. If you search foruploaded
in your crashlytics log you should see the upload logged. That's what's not happening for me. Make sense? On Linux / Windows: ~/.crashlytics/com.crashlytics.tools/crashlytics.log On Mac: ~/Library/Caches/com.crashlytics/com.crashlytics.tools/crashlytics.log
– Ewan
Nov 22 at 9:15
Thanks, yes I do have those lines in
proguard-rules.pro
and I don't have (indeed have never had) -printmapping mapping.txt
. I did have a lingering config.txt
file ( from earlier vn?) which had it and I deleted, to no effect. Now I have removed config.txt
. I'm interested to see if others see Deobfuscation file(s) uploaded.
in their crashlytics logs....– Ewan
Nov 21 at 22:15
Thanks, yes I do have those lines in
proguard-rules.pro
and I don't have (indeed have never had) -printmapping mapping.txt
. I did have a lingering config.txt
file ( from earlier vn?) which had it and I deleted, to no effect. Now I have removed config.txt
. I'm interested to see if others see Deobfuscation file(s) uploaded.
in their crashlytics logs....– Ewan
Nov 21 at 22:15
Where are you initializing Crashlytics? In a custom
Application
class?– MatPag
Nov 21 at 22:18
Where are you initializing Crashlytics? In a custom
Application
class?– MatPag
Nov 21 at 22:18
Yes (but don't think it's needed now). Crashlytics is working in that it's sending the stack trace. The problem is the stack trace is obfuscated. If you search for
uploaded
in your crashlytics log you should see the upload logged. That's what's not happening for me. Make sense? On Linux / Windows: ~/.crashlytics/com.crashlytics.tools/crashlytics.log On Mac: ~/Library/Caches/com.crashlytics/com.crashlytics.tools/crashlytics.log– Ewan
Nov 22 at 9:15
Yes (but don't think it's needed now). Crashlytics is working in that it's sending the stack trace. The problem is the stack trace is obfuscated. If you search for
uploaded
in your crashlytics log you should see the upload logged. That's what's not happening for me. Make sense? On Linux / Windows: ~/.crashlytics/com.crashlytics.tools/crashlytics.log On Mac: ~/Library/Caches/com.crashlytics/com.crashlytics.tools/crashlytics.log– Ewan
Nov 22 at 9:15
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53420776%2fcrashlytics-not-uploading-mapping-file%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown