Getting Started with Android Recording

A note on FullStory Native Mobile

Access to FullStory Native Mobile is dependent on your FullStory plan. Please contact your Account Executive or support@fullstory.com to learn more. 

About FullStory for Mobile Apps

FullStory for Mobile Apps includes and requires Private by Default technology that empowers product teams to debug experiences on native mobile applications while proactively respecting end-user privacy. Session replay for mobile apps isn't a screen recording and FullStory never captures screenshots from an end-user's device. Similar to FullStory for the web, where session replay represents a re-creation of a digital experience based on recorded changes in the DOM, FullStory's session replay for mobile apps is based on drawing operations, where text, images, and personal data are masked at the source by default, such that masked data never reaches FullStory's servers. 

Interested in using FullStory to understand and debug mobile app experiences? Request a demo or contact us to learn how to add FullStory for Mobile Apps to your current account plan.

 

Getting Started

Enabling native Android recording involves adding a Gradle plugin to your application. These instructions cover the simple process of adding this Gradle plugin to “modern” Android apps (developed in Android Studio) as well as “legacy” apps (migrated from Eclipse to Android Studio).


For modern Android apps

In modern Android application architecture, there are typically two build.gradle files that need to be modified when adding any Gradle plugins. These are:

  • The root build.gradle (by default located in the root folder), and
  • The app-specific build.gradle (by default located in the app/ folder).

The root build.gradle declares script plugin locations and classpaths. You’ll modify this file to point to the FullStory repository and add the FullStory plugin’s classpath (similar to how the Android Gradle plugin is declared).

In the app-specific build.gradle, you’ll apply the plugin and then declare a fullstory script block to configure some additional properties. This is analogous to how the Android application plugin is applied and the android configuration block is used for property declarations.

As you’re implementing the instructions below, you may find it useful to reference a sample app with a completed FullStory installation. If you would like a sample legacy app to review, please contact FullStory Support and reference this document.


Add the FullStory maven plugin to your buildscript

Paste the highlighted lines into the buildscript section of your root build.gradle, ensure that you replace <THE PLUGIN VERSION> with the correct version of the FullStory Android plugin. You can find the latest release notes here (this is currently 1.1.0)

buildscript {
  repositories {
google() jcenter() maven { url "https://maven.fullstory.com" } } dependencies { classpath 'com.android.tools.build:gradle:3.5.3' classpath 'com.fullstory:gradle-plugin-local:<THE PLUGIN VERSION>' // NOTE: Do not place your application dependencies here; they belong // in the individual module build.gradle files } }


Apply the FullStory plugin

Paste the highlighted lines into your app-specific build.gradle:

apply plugin: 'com.android.application'
apply plugin: 'fullstory'
fullstory {
  org '<YOUR ORG ID HERE>'
}
android {
  ...

Replace <YOUR ORG ID HERE> with your ORG ID, which you can obtain by logging into the FullStory application. Navigate to Settings > FullStory Setup, where you should see a line that looks like the following:window['_fs_org'] = 'XXXXX'; . This string is your ORG ID.

 

Instrumenting Debug Versions

By default, FullStory is only applied to the release variant of your app. That is, if your build variant contains the word “release”, we will add our instrumentation code to that APK after it is built.

By default, FullStory is only applied to the release variant of your app. To apply FullStory to all variants, including those used at debug time, add the following line below the org line:

org '<YOUR ORG ID HERE>'
enabledVariants 'all'

If you want FullStory to be applied to specific variants, you can also use a regular expression like so:

org '<YOUR ORG ID HERE>'
enabledVariants 'debug|release'

The variant name is constructed from the product flavor and build type (see example here). The FullStory build plugin will match the variant name case-insensitively.

 

Subclass from android.app.Application

FullStory requires that you enabled MultiDex and subclass your application from android.app.MultiDexApplication. To do that you need to have an App class that extends MultiDexApplication. If you do not have an Application class, create one, and in your App.java:

import android.app.MultiDexApplication;
public class App extends MultiDexApplication {
...
}

And set android:name="App" in your AndroidManifest.xml for <application> tag:

<application
android:name="App" ….

 

For legacy Android apps

Legacy Android apps that have been migrated from Eclipse to Android Studio have a single monolithic build.gradle file, rather than distinct root and app build.gradle files. As such, the FullStory installation process is identical to the process for modern apps, except that all modifications take place in the single build.gradle file. If you would like a sample legacy app to review, please contact FullStory Support and reference this document.

 

Identifying users and passing custom data to FullStory

On the Web, FullStory offers the FS.identify and FS.setUserVars JavaScript functions to enable you to enrich your FullStory data with additional variables for use in searches, segments, and integrations. This functionality is replicated on Android to allow you to pass user information to FullStory directly from your native app. The methods behave identically to their JavaScript counterparts linked above. The parameters are simply the Java equivalents of the original JavaScript parameters: FS.identify takes a String and an optional Map<String, Object>, while FS.setUserVars takes a Map<String, Object>.

As you're implementing the instructions above, you may find it useful to reference a sample app with a completed FullStory installation. If you would like a sample legacy app to review, please contact FullStory support (support@fullstory.com) and reference this document.


Additional topics

Privacy rules
For more information about configuring privacy rules and masking, please consult our Native Mobile Privacy Rules guide.

Turning mobile recording on or off
Mobile recording can be toggled on or off from Settings > Mobile Recording. This applies across your entire FullStory account.

Configuring domain whitelisting for WebViews
If your application makes use of WebViews, you must explicitly whitelist any domain you wish to record within a WebView. For security and privacy reasons, you should only whitelist domains which are under your control. Wildcards and subdomains are supported using the same scheme as Web domain settings. The key difference between the Web and Mobile settings is that while domain whitelisting is optional on Web, it is mandatory on Mobile if you wish to record content within WebViews. If your application doesn’t use WebViews or you don’t care to record within WebViews, you can safely ignore this section.

These settings can be configured from Settings > Mobile Recording.

Need to get in touch with us?

The FullStory Team awaits your every question.

Contact us