Firebase Crashlytics setCustomKeys stacked for all non-fatals

[READ] Step 1: Are you in the right place?

Yes

[REQUIRED] Step 2: Describe your environment

• Android Studio version: Android Studio Bumblebee | 2021.1.1 Patch 2
• Firebase Component: Crashlytics
• Component version: 29.0.0

[REQUIRED] Step 3: Describe the problem

Steps to reproduce:

1. Have a function which records exceptions & sets custom keys

fun recordException(message: String, customKeys: Map<String, String> = emptyMap()) {
  val crashlytics = Firebase.crashlytics
  crashlytics.setCustomKeys { customKeys.forEach { key(it.key, it.value) } }
  crashlytics.recordException(Throwable(message))
}

1. Call this function several times in a single app usage session

recordException("Non fatal without keys")
recordException("Non fatal with keys", mapOf("key_1" to "value_1"))
recordException("Non fatal with another keys", mapOf("key_2" to "value_2"))

Result: When the logs are flushed (at the next app start up) the custom keys are associated with all generated logs. Effectively this means that in the steps above all non fatal logs have the key_1 & key_2 associated with them.

Another defect caused by the issue is that if the app generates a lot of logs with keys (via recordException) is that after the 64th customKey no other keys are added.

This produces erroneous log trail by the app & messes up the search by key feature in the Firebase Crashlytics console.

Expected result: Based on this documentation I am left with the impression that the customKeys will be associated with the log they are fired for.

Note:

The iOS Crashlytics SDK has the capability of assigning keys for each log by using the userInfo in NSError, but that is not possible on Android (Java/Kotlin) because the Throwable does not provide such map (hence the SDK does not work in that way).

[dperez37]

I also ran into this issue. As far as I can tell setCustomKey() does the exact same thing on both iOS and Android. So I do not think there is an inconsistency there.

The userInfo property that iOS uses to set specific properties for the logged exception is a missing feature on Android. I think the real solution is not to change the setCustomKey() functionality but to add an overload to the recordException method allowing us to pass in a map of other values for the specific exception.

Something like this:

public void recordException(@NonNull Throwable throwable, @NonNull Map<String, String> userInfo)

[argzdev]

Hi @peterplamenovpenchev, thanks for reporting. I was able to reproduce the same behavior, I’ll notify an engineer and see what we can do here.