Android SDK integration for developers

Use one of the following methods to add the SDK to your app:

• [Best practice] Using Gradle
• Manually add the SDK

The Android Install Referrer improves attribution accuracy, protects from install fraud, and more. It is supported from AppsFlyer Android SDK version 4.8.6.

There are two ways to add the install referrer to your app:

• Use Gradle (recommended)
• Manually add the install referrer

Adding permissions helps increase the rate of Probabilistic modeling attribution. It also allows the SDK to send more data like Wifi and carrier network data. You can find this data in raw data reports and use it for analysis and optimization of campaigns.

Add Required Permissions

1. Add the following permissions to AndroidManifest.xml:
   

   <uses-permission android:name="android.permission.INTERNET" />
   <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
   <uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
   

The BroadcastReceiver gets information from Google Play that AppsFlyer uses for attribution. Using the BroadcastReceiver increases the attribution rate.

The following two options are available for implementing the install referrer BroadcastReceiver:

<application>
	<receiver android:name="com.appsflyer.SingleInstallBroadcastReceiver" android:exported="true">
		<intent-filter>
			 <action android:name="com.android.vending.INSTALL_REFERRER" />
		 </intent-filter>
	</receiver>
</application>

<application>
	<receiver android:name="com.appsflyer.MultipleInstallBroadcastReceiver" android:exported="true">
		<intent-filter>
			<action android:name="com.android.vending.INSTALL_REFERRER" />
		</intent-filter>
	</receiver>
</application>

AppsFlyer uses the dev key to uniquely identify your account. The dev key is mandatory because it allows the SDK to securely send and retrieve data that belongs to your AppsFlyer account.

Warning! Using the wrong dev key or an incorrect dev key impacts all traffic sent from the SDK and breaks attribution and reporting.

To retrieve your dev key:

1. Go to your app's dashboard.
2. In the dashboard, under Configuration click App Settings.
3. Copy your dev key.
   

   

Register the global application class

In the AndroidManifest.xml file, inside the application tag, add the following line:

android:name="<APP.PACKAGE.NAME>.<AFApplication>"

• <APP.PACKAGE.NAME> - replace this with the app package name.
• <AFApplication> - replace this with the name that you set for the global app class.

This line in manifest.xml tells the application what is the global application. As mentioned above, doing so makes the AppsFlyer SDK globally accessible throughout the app.

Initialize the SDK

We recommend initializing the SDK inside the app's global application class. This allows the SDK to initialize in all scenarios, including deep linking.

The steps listed below take place inside the app's global application class.

1. Inside the app's global class, import the following libraries
   

   import com.appsflyer.AppsFlyerLib;
   import com.appsflyer.AppsFlyerConversionListener;

2. Inside the global class, assign your dev key to a variable, preferably named AF_DEV_KEY.
   
   Java Kotlin

   public class AFApplication extends Application {
       private static final String AF_DEV_KEY = "qrdZGj123456789";
       
       //...
       
   }
   

   class AFApplication : Application() {
       private val devKey = "qrdZGj123456789";
   
       //...
       
   }
   

3. Inside the global class, after the call to super.onCreate(), implement the AppsFlyerConversionListener. See code below in step 4.
4. Inside the global class, after the ConversionListener, initialize the SDK using init() method. 
   
   Java Kotlin

   public class AFApplication extends Application {
       private static final String AF_DEV_KEY = "qrdZGj123456789";
       
       @Override
       public void onCreate() {
           super.onCreate();
           AppsFlyerConversionListener conversionListener = new AppsFlyerConversionListener() {
               @Override
               public void onConversionDataSuccess(Map<String, Object> conversionData) {
               
                       for (String attrName : conversionData.keySet()) {
                       Log.d("LOG_TAG", "attribute: " + attrName + " = " + conversionData.get(attrName));
                   }
               }
   
               @Override
               public void onConversionDataFail(String errorMessage) {
   		   Log.d("LOG_TAG", "error getting conversion data: " + errorMessage);
               }
   
               @Override
               public void onAppOpenAttribution(Map<String, String> attributionData) {
                   for (String attrName : attributionData.keySet()) {
                       Log.d("LOG_TAG", "attribute: " + attrName + " = " + attributionData.get(attrName));
                   }
               }
   
               @Override
               public void onAttributionFailure(String errorMessage) {
                   Log.d("LOG_TAG", "error onAttributionFailure : " + errorMessage);
               }
           };
           
           AppsFlyerLib.getInstance().init(AF_DEV_KEY, conversionListener, this);
   
       }
   }
                 

   class AFApplication : Application() {
       private val devKey = "qrdZGj123456789";
   
       override fun onCreate() {
           super.onCreate()
           val conversionDataListener  = object : AppsFlyerConversionListener{
               override fun onConversionDataSuccess(data: MutableMap<String, Any>?) {
                   data?.let { cvData ->
                       cvData.map {
                           Log.i(LOG_TAG, "conversion_attribute:  ${it.key} = ${it.value}")
                       }
                   }
               }
   
               override fun onConversionDataFail(error: String?) {
                   Log.e(LOG_TAG, "error onAttributionFailure :  $error")
               }
   
               override fun onAppOpenAttribution(data: MutableMap<String, String>?) {
                   data?.map {
                       Log.d(LOG_TAG, "onAppOpen_attribute: ${it.key} = ${it.value}")
                   }
               }
   
               override fun onAttributionFailure(error: String?) {
                   Log.e(LOG_TAG, "error onAttributionFailure :  $error")
               }
           }
   
           AppsFlyerLib.getInstance().init(devKey, conversionDataListener, this)
       }
   }
   

5. Inside the app's global class, call start().
   
   Java Kotlin

   AppsFlyerLib.getInstance().start(this);
   

   AppsFlyerLib.getInstance().start(this)

To delay initializing the SDK, you can call start from the Activity class.

This option can be used, if, for example, you need to postpone start until you receive user consent due to GDPR or CCPA requirements, etc.

When invoking start in Activity class:

• Make sure to pass Activity instance as an argument and not Application.
• If you plan to use deep linking features, add the start() API to any other Activity you to which you can deep link that doesn’t have start in it.

Before you start testing installs, register the test device.

Organic installs are unattributed installs which are usually direct installs from app stores.

To simulate an organic install:

1. Make sure you have a mobile device connected to your computer.
2. In Android Studio, open the Logcat.
3. From Android Studio, install the app on the device or emulator.
4. Wait for the app to launch.
5. In the Logcat, look for your app's package name.

You should see the following:

The highlighted part in the screenshot indicates that the SDK reports an organic install. This data comes from the onConversionDataSuccess method in the AFApplication class. Getting conversion data is discussed later in this guide.

Note: Starting SDK V5, onConversionDataSuccess is the name of the method for getting conversion data. If you are using an SDK version lower than 5.0.0, the name of the method is onInstallConversionDataLoaded . We recommend that you upgrade to SDK 5.0.0. To learn more, click here.

An organic install should now appear on the Overview page of the application's dashboard.

If you don't see an install in the app's dashboard, see our SDK troubleshooting guide.

A non-organic install is an attributed install that usually follows an ad engagement. You can simulate a non-organic install by using attribution links.

To simulate a non-organic install:

1. In the manifest, find out what is the package name of your app e.g. com.company.app.
   • In the URL below, replace <app_id> with your app's package name:
     

     https://app.appsflyer.com/<app_id>?pid=Test&c=Test

     For example:

     https://app.appsflyer.com/id0123456789?pid=Test&c=Test

   • The c parameter specifies the name of the campaign.
   • The pid parameter specifies the name of the media source to which the install is attributed.
   • Advertising ID (GAID) should be added if testing the click from a computer (by adding &advertising_id=<GAID> to the end of the link in step 1).
2. Send this URL to the device. You can do so for example by email or WhatsApp
3. On the device, click on the URL.
   • If the app is listed in the app store, you are redirected to the app store. Don't download and install the app from the app store. Proceed to step 5.
   • If the app is not listed in the app store and is still in development, the screen shows a message that the app is not available in the app store. Simply proceed to step 5.
4. In Android Studio, open the Logcat.
5. Connect the device to your computer using a USB cable.
6. From Android Studio, Install the app on the device.
7. In the Logcat, look for your app's package name.

You should see the following:

A non-organic install should now appear on the Overview page of the application's dashboard.

The SDK has two in-app event-related interfaces:

• AFInAppEventType - constants for in-app event names.
• AFInAppEventParameterName - constants for in-app event parameter names.

We strongly recommend using these two interfaces for the following reasons:

• The standard naming allows AppsFlyer to automatically map events to SRNs such as Facebook, Google, Twitter, and Snapchat.
• Backward compatibility - if AppsFlyer decides to change the name of any event or event parameter, your implementation is backward compatible.

To use these two interfaces, import them:

import com.appsflyer.AFInAppEventParameterName;
import com.appsflyer.AFInAppEventType;

Here is the list of recommended event names and structures.

You can send revenue with any in-app event. Use the af_revenue (AFInAppEventParameterName.REVENUE) event parameter to include revenue in the in-app event. You can populate it with any numeric value, positive or negative.

af_revenue is the only event parameter that AppsFlyer counts as real revenue on the raw data and dashboard. For more details, click here.

When sending events with revenue, keep the following in mind:

• If you set currency code (see example below), it should be a 3-character ISO 4217 code. (default is USD).
• You can set the currency code for all events by calling the following method: AppsFlyer.setCurrencyCode("ZZZ") To learn about currency settings, display, and currency conversion, see our guide on revenue currency.
• The revenue value should not contain comma separators, currency signs, or text. A revenue event should be similar to 1234.56, for example.

Example: In-app event purchase event with revenue

Map<String, Object> eventValue = new HashMap<String, Object>();
eventValue.put(AFInAppEventParameterName.REVENUE,1234.56);
eventValue.put(AFInAppEventParameterName.CONTENT_TYPE,"Shirt");
eventValue.put(AFInAppEventParameterName.CONTENT_ID,"1234567");
eventValue.put(AFInAppEventParameterName.CURRENCY,"USD");
AppsFlyerLib.getInstance().logEvent(getApplicationContext() , AFInAppEventType.PURCHASE , eventValue);

val eventValue = HashMap<String, Any>() 
eventValue.put(AFInAppEventParameterName.REVENUE,1234.56)
eventValue.put(AFInAppEventParameterName.CONTENT_TYPE,"Shirt")
eventValue.put(AFInAppEventParameterName.CONTENT_ID,"1234567")
eventValue.put(AFInAppEventParameterName.CURRENCY,"USD")
AppsFlyerLib.getInstance().logEvent(getApplicationContext() , AFInAppEventType.PURCHASE , eventValue)

The purchase event above has $1,234.56 in revenue associated with it, which appears as revenue in the dashboard.

Recording Negative Revenue

There may be situations where you want to record negative revenue.

For example, a user receives a refund for shoes that they purchased from you.

Map<String, Object> eventValue = new HashMap<String, Object>();
eventValue.put(AFInAppEventParameterName.REVENUE,-200);
eventValue.put(AFInAppEventParameterName.CONTENT_TYPE,"shoes");
eventValue.put(AFInAppEventParameterName.CONTENT_ID,"4875");
eventValue.put(AFInAppEventParameterName.CURRENCY,"USD");
AppsFlyerLib.getInstance().logEvent(getApplicationContext() , "cancel_purchase" , eventValue);

val eventValue = HashMap<String, Any>()
eventValue.put(AFInAppEventParameterName.REVENUE, -200)
eventValue.put(AFInAppEventParameterName.CONTENT_TYPE, "category_a")
eventValue.put(AFInAppEventParameterName.CONTENT_ID, "1234567")
eventValue.put(AFInAppEventParameterName.CURRENCY, "USD")
AppsFlyerLib.getInstance().logEvent(applicationContext,  "cancel_purchase", eventValue)

AppsFlyer’s SDK provides server receipt validation for in-app purchases. To validate a purchase, call the validateAndLogInAppPurchase.

This call automatically generates an af_purchase in-app event, given that the purchase is validated.

public static void validateAndLogInAppPurchase(Context context, 
String publicKey, String signature, String purchaseData, 
String price, String currency, HashMap<String, String> additionalParameters);

Method parameters

• String publicKey – public key from Google Developer Console.
• String signature – transaction signature (returned from Google API when the purchase is completed).
• String purchaseData – product purchased in JSON format (returned from Google API when the purchase is completed).
• String price – in-app event revenue to be reported to AppsFlyer.
• String currency – in-app event currency to be reported to AppsFlyer.
• HashMap<String, String> additionalParameters – additional parameters of the in-app event that appear in the event_value field in in-app event raw data.

Purchase validation success and failure callbacks

If you want to know if the attempt to validate the purchase is successful or not, implement registerValidatorListener in your application class. This listener has two callback blocks, one for ‘Success’ and one for ‘Failure’ (for any reason, including validation fail).

AppsFlyerLib.getInstance().registerValidatorListener(this,new
   AppsFlyerInAppPurchaseValidatorListener() {
     public void onValidateInApp() {
       Log.d(TAG, "Purchase validated successfully");
     }
     public void onValidateInAppFailure(String error) {
       Log.d(TAG, "onValidateInAppFailure called: " + error);
     }
});

AppsFlyerLib.getInstance().registerValidatorListener(this, object : AppsFlyerInAppPurchaseValidatorListener {
    override fun onValidateInApp() {
       	Log.d(LOG_TAG, "Purchase validated successfully")
    }

    override fun onValidateInAppFailure(error: String) {
        Log.d(LOG_TAG, "onValidateInAppFailure called: $error")
   }
})

Usage example of validating a purchase:

// Purchase object is returned by Google API in onPurchasesUpdated() callback
private void handlePurchase(Purchase purchase) {
    Log.d(LOG_TAG, "Purchase successful!");
    Map<String, String> additional_event_values = new HashMap<>();
    additional_event_values.put("some_parameter", "some_value");
    String price= "10";
    String currency = "USD";
    AppsFlyerLib.getInstance().validateAndLogInAppPurchase(getApplicationContext(), PUBLIC_KEY, purchase.getSignature(), purchase.getOriginalJson(), revenue, currency, additional_event_values);
}

// Purchase object is returned by Google API in onPurchasesUpdated() callback
private fun handlePurchase(Purchase purchase) {
   Log.d(LOG_TAG, "Purchase successful!");
   val additional_event_values = HashMap<String, String>()
   additional_event_values.put("some_parameter", "some_value");
   val price= "10";
   val currency = "USD";
   AppsFlyerLib.getInstance().validateAndLogInAppPurchase(this, PUBLIC_KEY, purchase.getSignature(), purchase.getOriginalJson(), revenue, currency, additional_event_values);
}

Validating an in-app purchase automatically sends an in-app purchase event to AppsFlyer. See below a sample data that is passed in the event_value parameter:

{
   "some_parameter":"some_value", // from additional_event_values
   "af_currency":"USD", // from currency
   "af_content_id":"test_id", // from purchase
   "af_revenue":"10", // from revenue
   "af_quantity":"1", // from purchase
   "af_validated":true // flag that AF verified the purchase
}

• Event name: up to 45 characters
• Event value: must not exceed 1000 characters - if longer we may truncate it
• Pricing and revenue: use only digits and decimals, e.g. 5 or 5.2
• Pricing and revenue values can have up to 5 digits after the period, e.g. 5.12345
• Non-English characters are supported, in in-app events,  other SDK APIs, starting from Android SDK V4.8.1.

You can record in-app events by calling logEvent with event name and value parameters. See In-App Events documentation for more details.

Below is a simple example of how to record a purchase event. For a comprehensive list of ready-made code snippets per vertical, see our guide for rich in-app events per verticals.

Example: In-app purchase event

Map<String,Object> eventValues = new HashMap<>();
eventValues.put(AFInAppEventParameterName.REVENUE, 1200);
eventValues.put(AFInAppEventParameterName.CURRENCY, "JPY");
eventValues.put(AFInAppEventParameterName.CONTENT_TYPE, "Shoes");
AppsFlyerLib.getInstance().logEvent(this, AFInAppEventType.PURCHASE, eventValues);

val eventValues = HashMap<String, Any>();
eventValues.put(AFInAppEventParameterName.REVENUE, 1200)
eventValues.put(AFInAppEventParameterName.CURRENCY, "JPY")
eventValues.put(AFInAppEventParameterName.CONTENT_TYPE, "Shoes")
AppsFlyerLib.getInstance().logEvent(this, AFInAppEventType.PURCHASE, eventValues)

If a user initiates an event when the internet connection is unavailable, Appsflyer is still able to record it. This is how it works:

1. SDK sends the events to AppsFlyer's servers and waits for a response.
2. If the SDK doesn’t receive a 200 response, the event is stored in the cache.
3. Once the next 200 response is received, the stored event is re-sent to the server.
4. If there are multiple events in the cache, they are sent to the server one promptly after another.

You can set a listener when recording in-app events. The listener allows you to define logic for two scenarios:

• In-app event recorded successfully.
• An error occurred when recording an in-app event.

AppsFlyerLib.getInstance().logEvent(getApplicationContext(), AFInAppEventType.PURCHASE, eventValue, new AppsFlyerRequestListener() {
                    @Override
                    public void onSuccess() {
                        Log.d(LOG_TAG, "Event sent successfully");
                    }
                    @Override
                    public void onError(int i, @NonNull String s) {
                        Log.d(LOG_TAG, "Event failed to be sent:\n" +
                                "Error code: " + i + "\n"
                                + "Error description: " + s);
                    }
                });

AppsFlyerLib.getInstance().logEvent(getApplicationContext(), AFInAppEventType.PURCHASE, eventValue, object : AppsFlyerRequestListener {
            override fun onSuccess() {
                Log.d(LOG_TAG, "Event sent successfully")
            }
            override fun onError(errorCode: Int, errorDesc: String) {
                Log.d(LOG_TAG, "Event failed to be sent:\n" +
                        "Error code: " + errorCode + "\n"
                        + "Error description: " + errorDesc)
            }
        })

In the event that an error occurs when recording the in-app event, an error code and string description are provided, as indicated in the table that follows.

OneLink detects the device type upon click and redirects the user to the matching destination, e.g. Google Play, iOS app store, out-of-store markets, or web pages.

The OneLink redirections guide discusses implementing multi-platform attribution links (no SDK coding required). It's also the basis for deep linking.

Deep linking allows you to send users to specific activities and serve them with customized content. This is especially useful when running retargeting campaigns.

To set up deep linking with OneLink, a marketer with access to AppsFlyer dashboard and a developer with access to the app must work together.

See our guide on setting up deep linking with OneLink.

Deferred deep linking allows you to deep-link new users and serve them with customized content after they install the app. This is unlike regular deep linking where the app needs to be already installed on the user's device.

To set up deferred deep linking with OneLink, the developer also needs access to the AppsFlyer dashboard.

The setup for deferred deep linking is the same as deep linking. The only difference is that you need to implement additional logic in the app in order to deep-link the users and serve them with customized content after they install and launch the app.

See our guide on deferred deep linking to learn more.

The SDK provides you with the conversion or engagement data following every install or deep linking event. You can use this data to customize content and the app's behavior programmatically.

To get deep linking data when the direct deep link is used and the app is opened, implement the onAppOpenAttribution method.

To get deep linking re-engagement data manually at any time, implement the performAppAttribution method. This allows access to re-engagement data without recording a new re-engagement.

See our guide on deep linking data to learn more.

The addPushNotificationDeepLinkPath method provides app owners with a flexible interface for configuring how deep links are extracted from push notification payloads.

By default, the SDK looks for a deep link value in the af key of a push notification’s JSON payload. However, many push providers use proprietary JSON schemas that the SDK can’t resolve without additional configuration.

addPushNotificationDeepLinkPath enables you to configure which key in the push notification’s payload the SDK uses for the deep link value.

Use this method if you’re integrating your app with push providers that don’t use the default push notification JSON schema the SDK expects.

When calling addPushNotificationDeepLinkPath, the SDK verifies that:

• The required key exists in the payload.
• The key contains a valid OneLink URL.

addPushNotificationDeepLinkPath must be called before calling start().

Basic configuration

Consider the following call to addPushNotificationDeepLinkPath

AppsFlyerLib.getInstance().addPushNotificationDeepLinkPath("deeply", "nested", "deep_link");                       

AppsFlyerLib.getInstance().addPushNotificationDeepLinkPath("deeply", "nested", "deep_link");

and these scenarios.

Scenario 1

Your app is invoked via push notification. It contains a payload structured as follows.

{
    ...
    "deeply": {
        "nested": {
            "deep_link": "https://yourdeeplink2.onelink.me"
        }
    }
    ...
}

In this scenario, the SDK extracts the value of deep_link and proceeds with the deep linking flow.

Scenario 2

Your app is invoked via push notification. It contains a payload structured as follows.

{
    ...
    "deeply": {
        "nested": {
            "banana": "https://yourdeeplink2.onelink.me"
        }
    },
    ...
}

In this scenario, when the call executes the SDK can't find the deep_link key in the payload. Therefore, nothing happens.

Scenario 3

Your app is invoked via push notification. It contains a payload structured as follows.

{
    ...
    "deeply": {
        "nested": {
            "deep_link": "Corrupted url or regular string"
        }
    },
    ...
}

In this scenario, although the SDK finds the deep_link key, its deep link value is invalid. Therefore, when the above call executes, nothing happens.

Advanced configuration

To configure multiple possible payload structures, call addPushNotificationDeepLinkPath multiple times:

• The first call that yields a valid deep link value is used
• Other calls are ignored

If none of the payload structures match or no valid OneLink URL is found in the payload, nothing happens.

For example, consider the following payload:

{
    ...
    "deeply": {
        "nested": {
            “deep_link”: “https://yourdeeplink2.onelink.me”
        }
    },
    “this”: {
        “is”: {
            "banana": "phone"
        }
    }
    ...
}

and the following calls to addPushNotificationDeepLinkPath.

// this.is.deep_link key isn’t found - nothing happens
AppsFlyerLib.getInstance().addPushNotificationDeepLinkPath("this", "is", "deep_link");
// this.is.banana key found, but contains invalid OneLink URL - nothing happens
AppsFlyerLib.getInstance().addPushNotificationDeepLinkPath("this", "is", "banana");
// deeply.nested.deep_link key found and contains valid OneLink URL - proceed deep linking flow
AppsFlyerLib.getInstance().addPushNotificationDeepLinkPath("deeply", "nested", "deep_link");

// this.is.deep_link key isn’t found - nothing happens
AppsFlyerLib.getInstance().addPushNotificationDeepLinkPath("this", "is", "deep_link");
// this.is.banana key found, but contains invalid OneLink URL - nothing happens
AppsFlyerLib.getInstance().addPushNotificationDeepLinkPath("this", "is", "banana");
// deeply.nested.deep_link key found and contains valid OneLink URL - proceed deep linking flow
AppsFlyerLib.getInstance().addPushNotificationDeepLinkPath("deeply", "nested", "deep_link");

With AppsFlyer, you can attribute installs for out-of-store Android apps. This allows you to promote your apps and reach larger audiences in markets where Google Play is not available

For more details on how to attribute installs for out-of-store apps, read here.

In pre-install campaigns, app owners can ask device manufacturers to pre-install their apps on devices before they leave the factory.

With AppsFlyer, you can easily attribute installs of pre-installed apps. When users launch your app for the first time, AppsFlyer attributes the install to the manufacturer as a media source.

For details, click here.

To learn how to set up uninstall measurement, read here.

If you want to receive a confirmation that the request was successfully received by the AppsFlyer servers, implement the AppsFlyerRequestListener listener.

The onRequestSuccess() callback method is invoked for every 200 response to an attribution request made by the SDK.

The onRequestFailure(String error) callback method is invoked for any other response and returns the response as the error string.

Implementation example

AppsFlyerLib.getInstance().start(getApplicationContext(), "devKey", new AppsFlyerRequestListener() {
            @Override
            public void onSuccess() {
                Log.d(LOG_TAG, "Launch sent successfully, got 200 response code from server");
            }
            @Override
            public void onError(int i, @NonNull String s) {
                Log.d(LOG_TAG, "Launch failed to be sent:\n" +
                                "Error code: " + i + "\n"
                                + "Error description: " + s);
            }
        });

AppsFlyerLib.getInstance().start(this, "devKey", object : AppsFlyerRequestListener {
            override fun onSuccess() {
                Log.d(LOG_TAG, "Launch sent successfully")
            }
            override fun onError(errorCode: Int, errorDesc: String) {
                Log.d(LOG_TAG, "Launch failed to be sent:\n" +
                        "Error code: " + errorCode + "\n"
                        + "Error description: " + errorDesc)
            }
        })

In the event that an error occurs during the request listener, an error code and string description are provided, as indicated in the table that follows.

The setAdditionalData API is required to integrate on the SDK level with several external partner platforms, including Segment, Adobe, and Urban Airship.
Use this API only if the integration article of the platform specifically states setAdditionalData API is needed.

setAdditionalData code example:

HashMap<String,Object> CustomDataMap = new HashMap<>();
CustomDataMap.put("custom_param_1","value_of_param_1");
AppsFlyerLib.getInstance().setAdditionalData(CustomDataMap);

val customDataMap = HashMap<String, Any>()
customDataMap.put("custom_param_1","value_of_param_1")
AppsFlyerLib.getInstance().setAdditionalData(customDataMap)

App owners using App Links for deep linking (without OneLink), and have a domain associated with their app can attribute sessions initiated via this domain using the appendParametersToDeepLinkingURL method.

For example, a user searches Google and clicks on your domain, www.example.com:

• If the user doesn’t have the app installed, they are directed to the website (www.example.com).
• If the user has the app installed on their device, they are deep linked into the app associated with www.example.com. The session is attributed to the media source (pid parameter) specified in appendParametersToDeepLinkingURL.

See the Android SDK reference for additional information.

Note: Smart Banners help app owners convert website visitors to app users.

By default, at least 5 seconds must pass between two app launches to count as two separate sessions (more about counting sessions).

Use the following API to set the minimum time between sessions:

AppsFlyerLib.setMinTimeBetweenSessions(int seconds);

Setting a high value to the custom time between launches may badly impact APIs relying on session data, such as deep linking.

You can report new user sessions using this SDK method. For example, this may be handy for utility apps that run in the background.

Use this API in your activity’s onCreate():

public void logSession(Context context);

Usage Example:

AppsFlyerLib.getInstance().logSession(context);

Some 3rd party services such as email service providers wrap links in emails with their own click recording domains. Some even allow you to set your own click recording domains. If OneLink is wrapped in such domains, it might limit its functionality.

To overcome this issue you can use the setResolveDeepLinkURLs API. Use this API to get the OneLink from click domains that launch the app. Make sure to call this API before SDK initialization.

For example, you have 3 click domains that redirect to your OneLink which is https://mysubdomain.onelink.me/abCD. Use this API to get the OneLink that your click domains redirect to. This API method receives a list of domains that the SDK resolves. Add the following code before SDK initialization.

AppsFlyerLib.getInstance().setResolveDeepLinkURLs("clickdomain.com", "myclickdomain.com", "anotherclickdomain.com");

The code above allows you to use your click domain while preserving OneLink functionality. The click domains are responsible for launching the app. The API, in turn, gets the OneLink from these click domains, then you can use the data from this OneLink to deep-link and customize user content.

With AppsFlyer, you can record push notifications as part of retargeting campaigns.

To enable this feature, call the sendPushNotificationData method inside the onCreate method of every activity that is launched after clicking the notification:

AppsFlyerLib.getInstance().sendPushNotificationData(this);

For more information on push notification measurement, read here.

Allowing your existing users to invite their friends and contacts as new users to your app, can be a key growth factor for your app. With AppsFlyer, you can attribute and record installs that originate from user invites within your app.

For details, see the User Invite Attribution article.

An AppsFlyer ID is created for every new install of an app. You can use AppsFlyer ID for various purposes:

• Send server-to-server in-app events.
• Match AppsFlyer ID with user records in your backend systems.
• Map entries when merging data from pull and push APIs.

Use the following API to obtain AppsFlyer ID:

public String getAppsFlyerUID(Context context);

Usage example:

String appsFlyerId = AppsFlyerLib.getInstance().getAppsFlyerUID(this);

To set your Customer User ID:

public void setCustomerUserId(String id);

Usage example:

AppsFlyerLib.getInstance().setCustomerUserId("myId");

We recommend setting the Customer User ID early in the app's flow, as it is only associated with events reported after its setup:

• If setCustomerUserId is called before calling start, the Customer User ID appears in the raw data reports for installs and for events.
• If it is set after, the Customer User ID is only associated with events that are recorded after setting the Customer User ID.

Getting Customer User ID:

To avoid setting the Customer User ID value again beyond the first launch, and to reduce calls to your server to get the customer user ID, you can check if its value is empty or not by using:

AppsFlyerProperties.getInstance().getString(AppsFlyerProperties.APP_USER_ID)

For more information about the Customer User ID, click here.

Delay SDK init for customerUserID

You can delay the SDK Initialization until the customerUserID is set.

To indicate that the SDK should delay initialization for the Customer User ID call:

AppsFlyerLib.getInstance().waitForCustomerUserId(true);

immediately before the init() method. The rest of the SDK initialization should remain unchanged.

Once the customerUserID has been provided, call

AppsFlyerLib.getInstance().setCustomerIdAndLogSession("customer_id", this);

to provide the SDK with the relevant Customer User ID and start the SDK.

The code should appear as follows:

public class AFApplication extends Application {
  private static final String AF_DEV_KEY = "qrdZGj123456789";
  @Override
  public void onCreate() {
    super.onCreate();
    AppsFlyerConversionListener conversionDataListener = 
    new AppsFlyerConversionListener() {
      ...
    };
    AppsFlyerLib.getInstance().waitForCustomerUserId(true);
    //WARNING! Removing above line doesn't cancel its effect.
    // Replace with this to stop waiting for CUID:
    // AppsFlyerLib.getInstance().waitForCustomerUserId(false);
    AppsFlyerLib.getInstance().init(AF_DEV_KEY, getConversionListener(), getApplicationContext());
    AppsFlyerLib.getInstance().start(this);
    // Do your magic to get the customerUserID
    // ...
    // any AppsFlyer SDK code invoked here will be discarded
   //Call the following API once the customerUserID is available:
 AppsFlyerLib.getInstance().setCustomerIdAndLogSession("customer_id", this);
  }
}

class AFApplication: Application() {
 private val afDevKey = ""

 override fun onCreate() {
  super.onCreate()
  val conversionDataListener = object: AppsFlyerConversionListener {
   ...
  }
  AppsFlyerLib.getInstance().waitForCustomerUserId(true);
  //WARNING! Removing above line doesn't cancel its effect.
  // Replace with this to stop waiting for CUID:
  // AppsFlyerLib.getInstance().waitForCustomerUserId(false);
  AppsFlyerLib.getInstance().init(afDevKey, conversionDataListener, this)
  AppsFlyerLib.getInstance().start(this)
  // Do your magic to get the customerUserID
  // ...
  // any AppsFlyer SDK code invoked here will be discarded
  // Call the following API once the customerUserID is available:
  AppsFlyerLib.getInstance().setCustomerIdAndLogSession("customer_id", this)
 }
}

To learn more about delaying the SDK initialization until the Customer User ID is available, go here.

From SDK Version 4.8.0 AppsFlyer automatically collects the google_advertising_id.

The requirement to collect the Google Advertising ID is only relevant for SDK versions 4.7.X and below.

At least one unique device identifier must be collected to enable attribution. The following identifiers are available: GAID, Android ID, IMEI, and OAID.

GAID - Google Advertising ID

Collected automatically from apps that contain Google Play Services. If GAID is available IMEI and Android ID should NOT be collected by the app to avoid violation of the Google Play policy.

IMEI and Android ID

Disabled by default. Can be collected ONLY for apps that do NOT contain Google Play Services.
Note: Starting with Android 10 (API level 29), released in late 2019, access to the IMEI parameter is restricted.

To send these IDs to AppsFlyer:

1. On app open collect the device IMEI and/or Android ID.
2. Call the following APIs BEFORE calling the start method:
   

   AppsFlyerLib.getInstance().setImeiData("IMEI_HERE");
   AppsFlyerLib.getInstance().setAndroidIdData("ANDROID_ID_HERE");

OAID - Open Advertiser Identifier

Guide to implementing OAID

Opting out of device ID collection

Developers can opt-out of collecting IMEI, Android ID, and OAID by using the following APIs: 

AppsFlyerLib.getInstance().setCollectIMEI(false);
AppsFlyerLib.getInstance().setCollectAndroidID(false);
AppsFlyerLib.getInstance().setCollectOaid(false);

In some extreme cases, you might want to shut down all SDK logging due to legal and privacy compliance. This can be achieved with the stop API. Once this API is invoked, the SDK stops functioning and no longer communicates with AppsFlyer servers.

AppsFlyerLib.getInstance().stop(true, getApplicationContext());

AppsFlyerLib.getInstance().stop(true, applicationContext);

There are several different scenarios for user opt-out. We highly recommend following the exact instructions for the scenario, that is relevant for your app.

The SDK can be reactivated by calling:

AppsFlyerLib.getInstance().stop(false, getApplicationContext());
AppsFlyerLib.getInstance().start(getApplicationContext(), <AF_DEV_KEY>);

AppsFlyerLib.getInstance().stop(false, applicationContext);
AppsFlyerLib.getInstance().start(applicationContext, <AF_DEV_KEY>);

Do not call start if stop is set to true. You can check the current state of the SDK by calling:

AppsFlyerLib.getInstance().isStopped() // returns true if SDK is stopped, false otherwise

AppsFlyerLib.getInstance().isStopped // returns true if SDK is stopped, false otherwise

Use this API during the SDK Initialization to explicitly anonymize a user's install, events, and sessions:

public void anonymizeUser(boolean isDisabled);

Usage example:

AppsFlyerLib.getInstance().anonymizeUser(true);

Logging can be restarted by calling anonymizeUser set to false.

In some cases, advertisers may want to stop sharing user-level data with ad networks/partners for specific users. Reasons for this include: 

• Privacy policies such as CCPA or GDPR
• User opt-out mechanisms
• Competition with some partners (ad networks, 3rd parties)

AppsFlyer provides two API methods to stop sharing data with some or all partners:

• setSharingFilter: Used by advertisers to set some (one or more) networks/integrated partners to exclude from getting data.
• setSharingFilterForAllPartners: Used by advertisers to exclude all networks/integrated partners from getting data.

These filtering methods are supported as of SDK V5.4.1.

The filtering method must be called every time the SDK is initialized and affects the whole session. If it takes time to determine whether you need to set the sharing filters, then delay the SDK initialization. 

When the method is activated before the first start call:

• Users from SRNs are attributed as Organic, and their data is not shared with integrated partners.
• Users from click ad networks (non-SRNs) are attributed correctly in AppsFlyer, but not shared with the ad networks via postbacks, APIs, raw data reports, or by any other method.

Currently, uninstall data can't be filtered using these methods. However, you can stop sending Uninstall events to partners using their setup pages in AppsFlyer.