Integrar SDK

Aprende a inicializar e iniciar el SDK para Android.

Sugerir ediciones

Antes de comenzar

  • Debes instalar el SDK para Android.
  • Asegúrate de que en tu app, en el archivo build.gradle , el applicationId (en el bloque defaultConfig ) coincide con el ID de la aplicación en AppsFlyer.
  • Obtén la clave de desarrollador de AppsFlyer. Se requiere para inicializar correctamente el SDK.
  • Los códigos de este documento son implementaciones de ejemplo. Asegúrate de cambiar el <YOUR_DEV_KEY> y otros marcadores de posición según sea necesario.
  • Todos los pasos de este documento son obligatorios a menos que se indique lo contrario.

Inicializar el SDK para Android

🐣
Obtener datos de conversión en Android
Fórmula abierta

Se recomienda inicializar el SDK en la clase/subclase de aplicación global. Eso es para garantizar que el SDK pueda iniciarse en cualquier escenario (por ejemplo, enlaces profundos).

Paso 1: Importar AppsFlyerLib
En tu clase de aplicación global, importa AppsFlyerLib:

import com.appsflyer.AppsFlyerLib;

import com.appsflyer.AppsFlyerLib

Paso 2: Inicializar el SDK
En la aplicación global onCreate, call init con los siguientes argumentos:

AppsFlyerLib.getInstance().init(<YOUR_DEV_KEY>, null, this);

AppsFlyerLib.getInstance().init(<YOUR_DEV_KEY>, null, this)
  1. El primer argumento es tu clave de desarrollador de AppsFlyer.
  2. El segundo argumento es un AppsFlyerConversionListeneranulable. Si no necesitas datos de conversión, te recomendamos pasar un null como segundo argumento. Para obtener más información, consulta Datos de conversión.
  3. El tercer argumento es el contexto de la aplicación.

Iniciar el SDK para Android

En el método onCreate de la aplicación, después de llamar a init, call start y pásalo en el Contexto de la Aplicación como primer argumento:

AppsFlyerLib.getInstance().start(this);

AppsFlyerLib.getInstance().start(this)

Deferring SDK start

OPCIONAL
Puedes diferir la inicialización del SDK llamando a start de una clase de actividad, en lugar de llamarla en la clase de aplicación. init aún debe llamarse en la clase de aplicación.

El uso típico del inicio diferido del SDK es cuando una aplicación desea solicitar el consentimiento del usuario para recopilar datos en la Actividad Principal y llamar a start después de obtener el consentimiento del usuario.

⚠️

Aviso importante

Si la aplicación llama a start desde una actividad, debe pasar el contexto de la actividad al SDK.
Si no se pasa el contexto de la actividad, no se activará el SDK, perdiendo así los datos de atribución y los eventos in-app.

Starting with a response listener

Para recibir la confirmación de que el SDK se inició correctamente, crea un objeto AppsFlyerRequestListener y pásalo como el tercer argumento de start:

AppsFlyerLib.getInstance().start(getApplicationContext(), <YOUR_DEV_KEY>, 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, <YOUR_DEV_KEY>, 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)
    }
})
  • The onSuccess() de devolución de llamada se invoca para cada 200 respuestas a una solicitud de atribución realizada por el SDK.
  • The onError(String error) de devolución de llamada se invoca para cualquier otra respuesta y devuelve la respuesta como la cadena de error.

Ejemplo completo

El siguiente ejemplo demuestra cómo inicializar e iniciar el SDK desde la clase de aplicación.

import android.app.Application;
import com.appsflyer.AppsFlyerLib;
// ...
public class AFApplication extends Application {
    // ...
    @Override
    public void onCreate() {
        super.onCreate();
        // ...
        AppsFlyerLib.getInstance().init(<YOUR_DEV_KEY>, null, this);
        AppsFlyerLib.getInstance().start(this);
        // ...
    }
    // ...
}

import android.app.Application
import com.appsflyer.AppsFlyerLib
// ...
class AFApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        // ...
        AppsFlyerLib.getInstance().init(<YOUR_DEV_KEY>, null, this)
        AppsFlyerLib.getInstance().start(this)
        // ...
    }
    // ...
}

Enlace de Github

Configuración del ID de usuario de cliente

OPCIONAL

The Customer User ID (CUID) is a unique user identifier created by the app owner outside the SDK. It can be associated with in-app events if provided to the SDK. Once associated with the CUID, these events can be cross-referenced with user data from other devices and applications.

Set the customer User ID

Once the CUID is available, you can set it by calling  setCustomerUserId.


...
AppsFlyerLib.getInstance().init(<YOUR_DEV_KEY>, conversionListener, this);  
AppsFlyerLib.getInstance().start(this , <YOUR_DEV_KEY> );
...
// Do your magic to get the customerUserID...
...
AppsFlyerLib.getInstance().setCustomerUserId(<MY_CUID>);

The CUID can only be associated with in-app events after it was set. Since start was called before setCustomerUserID, the install event will not be associated with the CUID. If you need to associate the install event with the CUID, see the below section.

Associate the CUID with the install event

If it’s important for you to associate the install event with the CUID, you should set it before calling start.

You can set the CUID before start in two ways, depending on whether you start the SDK in the Application or the Activity class.

When starting from the application class

Si iniciaste el SDK desde la clase Application class (see: Starting the Android SDK) and you want the CUID to be associated with the install event, put the SDK in waiting mode to prevent the install data from being sent to AppsFlyer before the CUID is provided.

To activate the waiting mode, set waitForCustomerUserId to true after init and before start.

📘Important

It's important to remember that putting the SDK in a waiting mode may block the SDK from sending the install event and consequently prevent attribution. This can occur, for example, when the user launches the application for the first time and then exits before the SDK can set the CUID. 

AppsFlyerLib.getInstance().init(<YOUR_DEV_KEY>, getConversionListener(), getApplicationContext());
AppsFlyerLib.getInstance().waitForCustomerUserId(true);
AppsFlyerLib.getInstance().start(this);

Después de llamar a start, you can add your custom code that makes the CUID available.

Once the CUID is available, the final step includes setting the CUID, releasing the SDK from the waiting mode, and sending the attribution data with the customer ID to AppsFlyer. This step is performed using the call to setCustomerIdAndLogSession.

AppsFlyerLib.getInstance().setCustomerIdAndLogSession(<CUSTOMER_ID>, this);

Aparte de setCustomerIdAndLogSession, no uses setCustomerUserId ni ninguna otra funcionalidad del SDK de AppsFlyer, ya que el SDK en espera lo ignorará.

Note

If you wish to remove the waiting mode from the SDK initialization flow, it is not enough to delete the call to waitForCustomerUserId(true). También hay que reemplazarla con waitForCustomerUserID(false). Simplemente eliminar la llamada es insuficiente porque el indicador booleano 'waitForCustomerUserId' se almacena en las Preferencias compartidas de Android.

Código de ejemplo

public class AFApplication extends Application {
  @Override
  public void onCreate() {
    super.onCreate();
    AppsFlyerConversionListener conversionDataListener = 
    new AppsFlyerConversionListener() {
      ...
    };
    AppsFlyerLib.getInstance().init(<YOUR_DEV_KEY>, getConversionListener(), getApplicationContext());
    AppsFlyerLib.getInstance().waitForCustomerUserId(true);
    AppsFlyerLib.getInstance().start(this);
    // Do your magic to get the customerUserID
    // any AppsFlyer SDK code invoked here will be discarded
    // ...
    // Once the customerUserID is available, call setCustomerIdAndLogSession(). 
    // setCustomerIdAndLogSession() sets the CUID, releases the waiting mode,
    // and sends the attribution data with the customer ID to AppsFlyer.
    AppsFlyerLib.getInstance().setCustomerIdAndLogSession(<CUSTOMER_ID>, this);
  }
}

When starting from the Activity class

Si iniciaste el SDK desde una clase Activity (see: Deferring SDK start) class and you want the CUID to be associated with the install event, set the CUID beforestart.

Log sessions

The SDK sends an af_app_opened message whenever the app is opened or brought to the foreground. Before the message is sent, the SDK makes sure that the time passed since sending the last message is not smaller than a predefined interval.

Setting the time interval between app launches

Llama a setMinTimeBetweenSessions to set the minimal time interval that must lapse between two af_app_opened messages. The default interval is 5 seconds.

Logging sessions manually

You can log sessions manually by calling logSession.

Cómo habilitar el modo de depuración

OPCIONAL
Puedes habilitar los registros de depuración llamando a setDebugLog:

AppsFlyerLib.getInstance().setDebugLog(true);

AppsFlyerLib.getInstance().setDebugLog(true)

📘

Nota

Para ver los registros de depuración completos, asegúrate de llamar a setDebugLog antes de invocar otros métodos SDK.

Ver ejemplo.

🚧

Advertencia

Para evitar la filtración de información confidencial, asegúrate de que los registros de depuración estén deshabilitados antes de distribuir la aplicación.

Pruebas de integración

OPCIONAL
Para obtener instrucciones detalladas sobre las pruebas de integración, consulta la guía de pruebas de integración del SDK de Android.

Actualizado hace 5 días