[Bug] [Crash] Fatal Exception: java.lang.NoSuchMethodError : ProcessDetailsProvider.getProcessName$com_google_firebase_firebase_sessions. Only Samsung-Android13 devices #1059
Comments
OguzFARSAK
changed the title
argzdev
added
api: crashlytics
api: performance
and removed
new
|
Hey @OguzFARSAK, thanks for reaching out. Did this issue happen after upgrading to version |
|
Hey @argzdev , Currently, we haven't updated the Firebase SDK in this version. In fact, we haven't updated it for the past few versions. This issue surfaced 2-3 days after we released the latest version; the crash rate spiked that day and then dropped the same day. There were no crashes for 1-2 days, but now there are occasional ones. It seems like the issue might be on your side because we haven't made any changes to our game during this period. I say again; for the first a few days it happened only Samsung devices, now the pattern changes" 
|
|
Thanks for the extra details, @OguzFARSAK. So for context, I'm trying to check which stable version of the Firebase SDK were you priorly using, before this issue was introduced. At first glance, it looks like the issue could be that the Firebase Unity SDK of Crashlytics has not included the Firebase Sessions library. According to the release notes, the Firebase sessions library was integrated in Crashlytics in Android on version That said, I'll reach out to our engineers and keep you posted once i get some feedback. |
|
still crashing stack: |
Avoid calling `Process.myProcessName()` on Android 13 because it appears to be missing from some OEM-specific Android 13 builds. It is fine to just let the method fall through to the next, older, method to get the process name. See firebase/firebase-unity-sdk#1059 I have not been able to reproduce this issue locally, but this change is very safe. We should consider refactoring Crashlytics to consume the Sessions `ProcessDetails` data class, instead of the current `@AutoValue` holder.
Avoid calling `Process.myProcessName()` on Android 13 because it appears to be missing from some OEM-specific Android 13 builds. It is fine to just let the method fall through to the next, older, method to get the process name. See firebase/firebase-unity-sdk#1059 I have not been able to reproduce this issue locally, but this change is very safe. We should consider refactoring Crashlytics to consume the Sessions `ProcessDetails` data class, instead of the current `@AutoValue` holder.
|
This was fixed in the latest version of Crashlytics and picked up by the latest Unity plugin |
|
i am using latest in my flutter project |
Avoid calling `Process.myProcessName()` on Android 13 because it appears to be missing from some OEM-specific Android 13 builds. It is fine to just let the method fall through to the next, older, method to get the process name. See firebase/firebase-unity-sdk#1059 I have not been able to reproduce this issue locally, but this change is very safe. We should consider refactoring Crashlytics to consume the Sessions `ProcessDetails` data class, instead of the current `@AutoValue` holder.
Description
ProcessDetailsProvider.getProcessName$com_google_firebase_firebase_sessions
This exception jumped yesterday and it occurs only Samsung (android13) devices and mostly at app start (<1 second)
No static method myProcessName()Ljava/lang/String; in class Landroid/os/Process; or its super classes (declaration of 'android.os.Process' appears in /system/framework/framework.jar!classes2.dex)
Reproducing the issue
No response
Firebase Unity SDK Version
11.9.0
Unity editor version
2022.3.30f1
Installation Method
.unitypackage
Problematic Firebase Component(s)
No response
Other Firebase Component(s) in use
No response
Additional SDKs you are using
Adjust, Facebook, GMA, GameAnalytics
Targeted Platform(s)
Android
Unity editor platform
Mac
Scripting Runtime
IL2CPP
Release Distribution Type
Pre-built SDK from https://firebase.google.com/download/unity
Relevant Log Output
No response
If using CocoaPods for Apple platforms, the project's Podfile.lock
Expand
Podfile.locksnippet👀 Replace this line with the contents of your Podfile.lock!The text was updated successfully, but these errors were encountered: