GameAnalytics | A fully-managed pipeline for game analytics | Continous Integration library

I'm a support engineer from GameAnalytics. The optimal way of creating games is to separate platforms with different keys for each one. There are a few benefits, the main one being the ability to link your game to the store and implement purchase validation. Since you can only link a pair of keys to 1 game in the store (Google Play or Appstore), that would also mean that you would also only be able to implement purchase validation for the game you linked. For example if you decided to link the Android version, you wouldn't be able to verify purchases of the iOS one.

Another benefit is that it makes it easier to debug any issues. It's just generally cleaner to separate the platforms and some SDKs don't even allow the use of the same pair of keys for multiple platforms (e.g. Unity), so it's not supported by default. They would either have to modify the SDK (not recommended) or use the collection API potentially.

Update Oct 19, 2020:

Today a developer updated the issue I linked in this answer saying the Firebase team fixed a backend bug last Friday (Oct 16) that was affecting some new Unity Android apps registering w/ Firebase - likely the bug behind your issue. I had already solved the issue in my own project using the below solution, but if you haven't yet updated your project, I recommend running it again and seeing if Crashlytics is working for you now..

I've been dealing with the same issue this week in Unity 2019.4.11f1 - i see the same error message about not being able to retrieve settings, but with my specific project and appIds in the URL.

I found a solution in this Github issue, which suggests the problem is caused by the version of an android library that is a dependency for the Unity Firebase Crashlytics package. My rough understanding is that the firebase-crashlytics-unity library is a wrapper around android library firebase:firebase-crashlytics, and the unity package allows the underlying native Android code to be used from Unity. Version com.google.firebase:firebase-crashlytics:17.10.0 has issues with getting the settings for some Firebase projects on Android. Myself and several others following this issue found forcing Unity to use this specific dependency at version 17.1.1 resolved the issue.

Someone else with the same issue in the thread contacted Firebase support and was told:

The error you are seeing "Failed to retrieve settings" is related to the SDK version being used. If you go to "Assets > Firebase > Editor> CrashlyticsDependencies" you can manually update the SDK to point to the latest Crashlytics SDK version 17.2.2. Please give it a try and if you continue having issues, let me know.

It turned out this advice wasn't quite right - some of us following the thread then experienced a different issue when using the Android Crashlytics SDK version 17.2.2 with Unity crashlytics version 6.16.0. So I'd specifically recommend trying out the below suggestion or other solutions in the thread to set your Android crashlytics library to v17.1.1.

Changes I made in my project to address this:

• First, I updated my unity firebase packages in the package manager to use version 6.16.0. In my project 4 packages were installed - core, analytics, crashlytics, and messaging.
• Then I searched for the the Crashlytics package's dependency file - Crashlytics-Dependencies.xml (found by searching project - was in /Library/PackageCache/com.google.firebase.crashlytics@6.16.0/Firebase/Editor/ for me). This file initally had "com.google.firebase:firebase-crashlytics:17.0.0" listed, which I updated to be: "com.google.firebase:firebase-crashlytics:17.1.1".
• As an extra precaution, I also added created a MyProject-Dependencies.xml file, as was suggested by a user in the thread - this file also specifies version "com.google.firebase:firebase-crashlytics:17.1.1".
• Next, I modified the Unity build process to use a custom mainTemplate.gradle file to specify dependencies, rather than using the External Dependency Resolver to manage and embed unity packages (option in Build Settings > PlayerSettings > Android).
• I also updated the settings on the External Dependency Manager Android Ressolver:
  • Disabled AutoResolve and Disabled Resolve on Build (we dont want EDM updating dependencies without our knowledge when building)
  • I also turned disabled AndroidPackageInstallationEnabled - this has made the resolution process much faster and removed a bunch of .aar files from the android dependencies list, and hasn't caused any problems in my project.
• I then ran External Dependency Resolver > Android > Force Resolve, which after the settings changes above, should now embed a list of the dependencies for the Android build into the mainTemplate.gradle file - Check this file (its in Assets/Plugins/Android) and you should now see com.google.firebase:firebase-crashlytics:17.1.1 in that list.

Also, I recommend reading this article about managing Unity Firebase dependencies from one of the Firebase developer advocates, Patrick Martin. It helped me wrap my head around how Android dependency management in Unity works, as well as how the Android gradle build process works.

Description: The general problem is to have any piece of code that blocks the Main Thread on iOS when the application is finalizing (see this document for more information). In our case it is happening because of ongoing requests when the player kills the application. As we save the player progress on the server when the application is terminated (using Dispose() method), the request blocked the main thread, causing the crash. The solution is to remove this particular save. We tested a build including this fix and, so far, we have no crashes on 20 attempts of killing the game after the Game Scene is loaded. We haven't thought about this before because this piece of code is there since August of 2019 and it hasn't been touched since then. The problem started to happen only in February of 2020.

More information: Since the piece of problematic code was in the project since August of 2019 and the problem started to happen only on February of 2020, it's possible that the iOS version has something to do with it. We haven't investigate the changelog yet, but the oldest iOS version presenting the crash so far is iOS 13.2, released on October 28th, 2019.

Another possibility is that some change on our backend code caused the request to hang. As we use BestHTTP, by default all requests are aborted when the application is terminated. We haven't investigate if the execution order of Dispose vs. OnDisable/OnApplicationQuit can be the issue. Also, by default, the requests aborted by BestHTTP during Application Quit still call the callbacks. In our case, the callback for that Save Player is null, so this might not be the problem.

Related crashes: We're still facing some crashes on the loading scene. As far as we've seen, they happen when there's a request going on. The reproduction rate of those issues are way lower than the problem on Game Scene.

Hints: We had difficulty to retrieve the logs on Crashlytics, because most of them weren't being send. Here's a step-by-step of how to retrieve the log from the iOS device itself:

1. Open the Settings app on your iPhone/iPad device
2. Go to Privacy (appears below Battery on iOS 13)
3. Scroll to the bottom and open Analytics & Improvements
4. Open Analytics Data
5. Find the logs for the desired application