Skip to content

Instantly share code, notes, and snippets.

@jakeouellette
Last active February 8, 2019 23:45
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save jakeouellette/42f0615f9c5c557b540dac7ae639a6f9 to your computer and use it in GitHub Desktop.
Save jakeouellette/42f0615f9c5c557b540dac7ae639a6f9 to your computer and use it in GitHub Desktop.

Fabric Android shell

Overview

This is the doc for fabric-android-shell.sh

Invoking the Fabric plugin by standalone (non-jvm) processes So our plugin has 3 responsibilities:

  • (pre-build) Enable your app on our backend
  • (pre-build) Injecting a build ID to associate those mapping files to that build
  • (post-build) Upload mapping files

This shell script breaks down those steps into two functions: pre-build and post-build.

When this jar runs, output is logged to a folder.

  • On Linux / Windows: ~/.crashlytics/com.crashlytics.tools/crashlytics.log
  • On Mac: ~/Library/Caches/com.crashlytics/com.crashlytics.tools/crashlytics.log

Mapping files are also cached in a folder relative of /com.crashlytics.tools/

Build steps

get_fabric_tool (optional)

This is a quick-and-dirty tool to bootstrap downloading the plugin if you don't have access to a dependency manager. Please replace this with a real maven-protocol backed dependency manager if you're able.

Pre-Build steps

The pre-build steps include generating the ID enabling the app on our backend. This step must run after the manifest is processed and the assets are merged. This is because:

  • Plugin is reading the manifest, and adding assets
  • Plugin is adding assets (the asset is for beta distribution, see: https://fabric.io/features/distribution )
  • Plugin is adding a resource (used to deobfuscate crashes)

Post-Build steps

Cache the mapping file, then try to upload it after every build.

Parameters

Build ID

IMPORTANT: This build_id must match between pre_build and post_build If you call this script twice, it will be different, so you may want to inject it into the script. It can be generated via uuidgen, We generate it via java.util.UUID.randomUUID().toString()

preserve_build_id

You can speed up your build slightly by only updating this ID for release builds, feel free to parameterize this. Can be false, whenever, but faster if you set true for:

  • Normal non-release builds
  • Instant run non-release builds
  • Non-proguarded apps in general

mapping_file

Path your mapping file is generated. In Gradle, this is variant.mappingFile

project_path

Root path of the app project, likely .

manifest_path

This should be the generated build/ manifest during the build for the variant In Gradle, we use variant.outputs[0].processResourceTask.manifestFile.toString()

base_manifest_path

This is a pointer to a real root manifest on disk. In Gradle, we use src/main/AndroidManifest.xml if you run this from the app/ folder

res_path

Resource path for the variant, we use project.android.sourceSets.main.res.srcDirs.find { it.exists() }

assets_path

Asset path for the variant, we use assetsPath = project.android.sourceSets.main.assets.srcDirs.find { it.exists() }

target_res_value_dir

This is where we will put the build id during the build when the generate resources task is called Currently, in modern Android Gradle plugin, there's a task, variant.registerResGeneratingTask, that we call. We pass into that task project.buildDir + "/generated/fabric/res" + variant.dirName

properties

This is optional and can safely be empty. We use this to allow open source projects to inject in their api key from an uncommitted file. ( see: https://docs.fabric.io/android/fabric/settings/working-in-teams.html?highlight=apikey )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment