Forem: Francis Ilechukwu

Getting Readable Crash Reports in Firebase Crashlytics from your Flutter Application

Francis Ilechukwu — Wed, 14 Aug 2024 00:38:00 +0000

Introduction
Android
iOS
Conclusion

Introduction

Many of us have deployed mobile applications to pre-production/production environments and got an email from Firebase saying "Heads up! We detected a new fatal issue in !" if you integrated Firebase crashlytics.

You wonder what it could be about, and head over to the firebase console under the crashlytics section to find out nothing makes sense, everything looks like a hexadecimal fest.

In this article, we'll look at steps to take for both Android & iOS applications built with Flutter to ensure our crash reports are readable for every app version we release.

Before we get into it, Flutter is an open-source cross-platform development kit that supports but is not limited to Android and iOS and will generate binaries for these platforms when instructed to.

These binaries may be in .aab or .apk format for Android and in .ipa for iOS.

It's safe to say that if you stumbled upon this article, you already understand what obfuscation means

In any case, obfuscation is a means by which during the compilation of an application, the resulting symbols or tokens that you as the developer understand and can make meaning of in the first instance, are obscured. i.e. functions, classes, and variable names will be rendered meaning less, thus making it extremely hard to reverse-engineer. This is a security measure that production-grade applications go through.

This is why stack traces or error messages on the crashlytics dashboards are a bunch of gibberish without the steps we will go into detail on.

If Firebase crashlytics was set up properly, you probably don't need to read this article. But for some wired reason, I've set up a couple of Flutter applications with Firebase crashlytics following all the steps in the official documentation and I still get the warning for missing dSYM files for iOS even though there are build steps that are meant to take care of this. If you are in the same situation, then read on.

Before we proceed, I assume that you've already integrated Firebase crashlytics with your Flutter application for Android and iOS. If you've not done that, See Integrating Firebase Crashlytics with your Fluter Application

Android

When developing Android applications using Flutter and you want obfuscation enabled, you'd pass the --obfuscate flag and the --split-debug-info argument. The --split-debug-info flag is the most important argument for what we want to achieve as this tells the flutter binary where to output the debug symbols files.

We'll upload these files to Firebase using the Firebase CLI tool.

Here's a full flutter build command that obfuscates the resulting application and outputs the debug symbols to a specified path

flutter build apk --target-platform android-arm,android-arm64,android-x64 --release --obfuscate --split-debug-info=build/app/outputs/symbols --verbose

So we've told Flutter to output debug symbols to the path build/app/outputs/symbols. Note that the path will be created if it doesn't exist.

The next step is to use the Firebase CLI tool. If you don't have it installed, use the below command to do so

curl -sL https://firebase.tools | bash

And then use the below to log in to your Firebase account

firebase login

To upload the debug symbols, you then use the command below while pointing to the folder containing the debug symbols

firebase crashlytics:symbols:upload --app=FIREBASE_APP_ID build/app/outputs/symbols

You can obtain FIREBASE_APP_ID from your 'Project Settings' page in the Firebase console as shown below

If running the firebase crashlytics:symbols:upload command in a CI environment like GitHub Actions, set an environment variable GOOGLE_APPLICATION_CREDENTIALS to point to the location of your service account .json key file.

Below is a typical re-usable and manually dispatchable GitHub Actions workflow that downloads the symbols folder as a zipped artifact, extracts it, and uploads it to Firebase. the workflow is expected to be re-used by an actual job in a workflow consisting of other jobs.

name: upload-flutter-debug-symbols-to-firebase

on:
  workflow_dispatch:
    inputs:
      flutter-debug-symbols-artifact-name:
        description: AAB Artifact Name.
        required: true
        type: string
  workflow_call:
    inputs:
      flutter-debug-symbols-artifact-name:
        description: AAB Artifact Name.
        required: true
        type: string
    secrets:
      FIREBASE_APP_ID:
        description: Firebase App ID
        required: true
      FIREBASE_SERVICE_ACCOUNT_JSON_CONTENT:
        description: Firebase Service Account Key Content
        required: true

jobs:
  upload-debug-symbols:
    name: Upload Flutter Debug Symbols to Firebase
    runs-on: ubuntu-latest
    steps:
      - name: Install Firebase Tools
        run: curl -sL https://firebase.tools | bash

      - name: Download Flutter Debug Symbols
        uses: actions/download-artifact@v2
        with:
          name: ${{ inputs.flutter-debug-symbols-artifact-name }}

      - name: Extract Flutter Debug Symbols
        run: unzip -q ./symbols.zip -d symbols

      - name: Prepare Google Service Account Credential
        run: echo '${{ secrets.FIREBASE_SERVICE_ACCOUNT_JSON_CONTENT }}' >> firebase-service-account.json

      - name: Upload Flutter Debug Symbols to Firebase
        env:
          GOOGLE_APPLICATION_CREDENTIALS: firebase-service-account.json
        run: firebase crashlytics:symbols:upload --app=${{ secrets.FIREBASE_APP_ID }} ./symbols

iOS

Running the flutterfire configure command after integrating your Flutter project with Firebase crashlytics will attempt to add a run script to your project’s Xcode workspace that finds and uploads the necessary dSYM symbol files to Crashlytics. Without these files, you’ll see a "Missing dSYM" alert in the Crashlytics dashboard and exceptions will be held by the backend until the missing files are uploaded - firebase.google.com.

If you did not use flutterfire configure or did and you still get the "Missing dSYM" alert from Firebase, you will need to follow through on the steps from the highlighted text downwards

Sometimes, the steps in the official documentation (previous link) don't help and sometimes cause the build process to fail depending on the complexity of your application, especially when you use the --split-debug-info argument and the optional --obfuscate flag.

There's also the question of build schemes or flavors, concerning which Firebase credentials will be used while executing the script.

If you've followed through with the links above and still not getting readable crash reports from the Firebase console, two things are certain at this point.

You have an upload script present at ios/Pods/FirebaseCrashlytics/upload-symbols After a successful build process, + dSYMs are being generated at build/ios/archive/Runner.xcarchive/dSYMs.

To upload your dSYM files, the command should be somewhat like this

ios/Pods/FirebaseCrashlytics/upload-symbols -gsp <Absolute-Path-To-Flutter-Project-Root>/ios/Runner/GoogleService-Info.plist -p ios <Absolute-Path-To-Flutter-Project-Root>/build/ios/archive/Runner.xcarchive/dSYMs

The concept is the same in workflow or flavored or multi-build scheme Flutter iOS apps

Conclusion

Crash reports are essential for improving and maintaining the stability of any application as they help you identify issues before they become a major disaster. Hopefully, this article will help you achieve stability in your Flutter apps.

A Package Manager for Code Igniter 3

Francis Ilechukwu — Tue, 19 Mar 2019 04:35:54 +0000

Code Igniter is a simple and yet powerful PHP MVC Framework. With it, one can build rich featured web applications in almost half the time required to write the same application in plain PHP while taking care of security issues at the same time.

I have used Code Igniter for about 3 years to know that it’s core is really efficient and is one of the most simplest MVC framework out there.

As small and simple as it is, its applications ranges from simple to very complex projects.

There are only two reasons I can think of so far, that the framework has lacked over the years which prompted people to choose its alternative (Laravel) to it.

The first reason is its failure to adapt to the new PSR-4 Auto-Loading feature that PHP rolled out. You’ll notice this when you try to load the same class name but in different directories as Code Igniter 3 was built to adapt to PHP 5.3.+ and has a built-in preventive mechanism to avoid clashing of class names.

The code in the controller below will load only the library assigned to alias1

<?php
defined('BASEPATH') OR exit('No direct script access allowed');
class MainController extends CI_Controller {

  function index() {
    $this->load->library("nodes/Lib", null, "alias1");
    $this->load->library("Lib", null, "alias2");
  }
}
?>

This problem is currently being solved by Code Igniter 4 which is currently in Beta.

The second reason is, unlike Laravel, Code Igniter does not have a repository for packages that can save you a lot of development time like Packagist.

you may get libraries from GitHub but you still need to modify/copy them to the right directory in the right structure by yourself to suit Code Igniter before you can use them.

Some of the libraries you may find, implement functionalities that already reside within Code Igniter, hence re-inventing the wheel. You won’t want to do this if you are the one writing a library unless it’s necessary.

Splint is a Package and Dependency manager specifically built for Code Igniter to allow one build mini applications, packages that can make use of the Code Igniter Loader to load resources such as views, models, configs, libraries, etc. Whatever you can do within Code Igniter applications, you can do also within Splint packages.

Loading and using a library within a Splint package is as easy as shown below.

<?php
$this->load->splint("francis94c/ci-preference", "+CIPreferences", null, "prefs");
$this->prefs->get("key");
?>

As you can see, the splint() function isn’t by default, a member of the loader class. However, you will need to modify the Loader class from the application/core folder. The Splint Terminal tool will do this automatically for you whenever you install a package.

Splint has a Wiki where you can learn all about how to build Splint packages. However, Splint is still very much new and has very few packages you can make use of. You can always go to their website to see the packages they have that you can install.

Installing a package using the Splint Terminal tool is as easy ascan be with the following command.

splint install vendor/package_name

Splint also has an SDK which is in fact, a complete Code Igniter distribution with its loader already modified along with one platform package for use when developing/testing a package.

All packages must be publicly hosted on GitHub before you can import them to Splint.

A Sample Splint Package

Let’s take a look at the Splint package I built for persistence of simple key-value pairs. I call the package ci-preference and is hosted on GitHub. You can visit it’s Splint page here.

This library makes use of two main functions which are set() and get() to set values and get values by key.

All you have to do to use this library in Code Igniter is to download the Splint terminal tool and run splint install francis94c/ci-preference to have the package installed within your Code Igniter distribution.

Then within any controller/model, use the package as described in its README which you would find either on the Splint page for the package or on it’s GitHub page.

<?php
defined('BASEPATH') OR exit('No direct script access allowed');
class A_Controller extends CI_Controller {

  function index() {
    $params = array();
    $params["file_name"] = "preferences"; // File name of the preference file.
    $this->load->splint("francis94c/ci-preference", "+CIPreferences", $params, "alias");
    $this->alias->get("key", "defaultVal");
    $this->alias->set("key", "val");
    $this->alias->increment("key1", 5) // Increments 'key1' by 5.
    $this->alias->increment("key1") // increments 'key1' by 1.
    $this->alias->concat("key2", "A") // Concatenates 'A' to 'key2'.
    $this->alias->commit(); // Commits all values to file.
  }
}
?>

That’s all about it. If you have ideas about libraries you would like to build and use within Code Igniter, have a look at the Developer Docs for Splint.

You can also modify other libraries/packages out there to suit Code Igniter and publish/import it to Splint as that will surely, go a long way in helping the Code Igniter community.