Skip to main content

Uploading Android Symbol Files

To upload symbol files, the Memfault CLI must be used.


This guide assumes the Memfault CLI tool installed. If it is not installed it yet, please follow the installation instructions.

Uploading Android OS symbol files

While processing Traces from diagnostic data, Memfault will attempt to provide source file and line numbers for stackframes from native binaries. In order to do this, the symbol files for these native binaries need to be uploaded to Memfault.

When building the Android OS, the final image will contain executables from which the symbols (debug info) has been stripped. Usually, "unstripped" versions of the executables are also kept in the build output. For example, in builds of recent versions of AOSP, they are output in out/target/product/generic/symbols/**. The exact location may be a bit different for your project. To test whether a file contains symbols, check out this article.

To upload all symbol files, run this command:

$ memfault upload-aosp-symbols out/target/product/generic/symbols

It's best to hook this into Continuous Integration when a build is released for internal consumption so that Memfault will immediately have the ability to symbolicate crashes.

The command will run through all files in the given directory. For each file, it will check whether it's a symbol file that has not yet been uploaded and upload it if necessary. The output of the command looks like this:

INFO: /aosp/symbols/out/target/product/vsoc_x86/symbols/init: ELF file with .debug_info and GNU Build ID: 706b026c8cc3e970b409d79c11c182a5
INFO: /aosp/symbols/out/target/product/vsoc_x86/symbols/init: uploaded!
INFO: /aosp/symbols/out/target/product/vsoc_x86/symbols/apex/ ELF file with .debug_info and GNU Build ID: 37398ca3d0492ba8b1e708a13ab2f9e0
INFO: /aosp/symbols/out/target/product/vsoc_x86/symbols/apex/ uploaded!
INFO: /aosp/symbols/out/target/product/vsoc_x86/symbols/apex/ ELF file with .debug_info and GNU Build ID: a2a7ab7cea9d8c482f31b3ee3a71c5ee
INFO: /aosp/symbols/out/target/product/vsoc_x86/symbols/apex/ skipping, already uploaded.
... etc ...

Uploading Android App symbol & mapping files

For traces in a that originate from an Android app, Memfault will also attempt to provide source file and line numbers for stackframes from both native/C/C++ (NDK) code as well as Java code.

For Android apps that use the Android NDK or JNI (Java Native Interface), binary symbol files will need to be uploaded for each version of an app.

In case the app has been obfuscated or minimized by R8 (or Proguard), the associated mapping file (mapping.txt) will need to be uploaded as well for each version of an app.

Using the upload-android-app-symbols command

The easiest way to upload all required files in one go, is using the upload-android-app-symbols command, passing the build variant and path to the Android app build output directory:

$ memfault upload-android-app-symbols \
--build-variant release <APP_SOURCE_ROOT>/build

The command will use the .apk in the build tree to automatically infer the package identifier, the version code and version name. It will then upload the binary symbol files (only applicable if the app uses the NDK) and upload the mapping file (only applicable if the app has R8 or Proguard enabled).

If this automatic behavior does not work in your use case, consider using option flags (i.e. --version-code, --version-name, --package, etc.) to specify the required information directly. You can run memfault upload-android-app-symbols --help to get more information on the all the options.

Proguard / R8 configuration

If you are using Proguard / R8 minification/obfuscation, it is recommended to enable the -keepattributes LineNumberTable configuration option in your app's file:

# Uncomment this to preserve the line number information for
# debugging stack traces:
-keepattributes LineNumberTable

Without this option, the generated mapping.txt file will not contain enough information for Memfault to be able to fully deobfuscate stack traces from the app.