Guias

Integrar o SDK

Saiba como inicializar e iniciar o Android SDK.

Sugerir edições

Antes de começar

Get started with our SDK integration wizard

Inicializando o SDK do Android

É recomendável inicializar o SDK na classe/subclasse global Aplicativo. Isso é para garantir que o SDK possa começar em qualquer cenário (por exemplo, deep links).

Etapa 1: importar AppsFlyerLib
Na classe global do seu aplicativo, importe AppsFlyerLib:

import com.appsflyer.AppsFlyerLib;

import com.appsflyer.AppsFlyerLib

Etapa 2: inicializar o SDK
No aplicativo global onCreate, call init com os seguintes argumentos:

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

AppsFlyerLib.getInstance().init(<YOUR_DEV_KEY>, null, this)
  1. O primeiro argumento é sua chave do desenvolvedor da AppsFlyer.
  2. O segundo argumento é um Nullable AppsFlyerConversionListener. Se você não precisa de dados de conversão, recomendamos passar um null como o segundo argumento. Para obter mais informações, consulte Dados de conversão.
  3. O terceiro argumento é o Contexto do Aplicativo.

Iniciando o SDK do Android

No método onCreate do Aplicativo, depois de chamar init, call start e passar o contexto Aplicativo como o primeiro argumento:

AppsFlyerLib.getInstance().start(this);

AppsFlyerLib.getInstance().start(this)

Deferring SDK start

OPCIONAL
Você pode adiar a inicialização do SDK chamando start de uma classe de atividade, em vez de chamá-lo na classe Aplicativo. init ainda deve ser chamado na classe Aplicativo.

O uso típico do início adiado do SDK é quando um aplicativo deseja solicitar o consentimento do usuário para coletar dados na atividade principal e chamar start após obter o consentimento do usuário.

⚠️

Aviso importante

Se o aplicativo chamar start de uma atividade, ele deve passar o Contexto da atividade para o SDK.
Deixar de passar o contexto da atividade não acionará o SDK, perdendo assim dados de atribuição e eventos in-app.

Starting with a response listener

Para receber a confirmação de que o SDK foi iniciado com sucesso, crie um objeto AppsFlyerRequestListener e passe-o como o terceiro 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() é chamado para cada resposta 200 para uma solicitação de atribuição feita pelo SDK.
  • The onError(String error) é chamado para qualquer outra resposta e retorna a resposta como a sequência de caracteres de erro.

Exemplo completo

O exemplo a seguir demonstra como inicializar e iniciar o SDK a partir da classe Aplicativo.

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)
        // ...
    }
    // ...
}

Link do Github

Definindo o ID de usuário 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

Se você iniciou o SDK a partir da classe 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.

⚠️

Importante

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);

Depois de chamar 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);

Além de setCustomerIdAndLogSession, não use setCustomerUserId ou qualquer outra funcionalidade do SDK da AppsFlyer, pois o SDK em espera irá ignorá-la.

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). Também é necessário substituí-lo por waitForCustomerUserID(false). Simplesmente remover a chamada é insuficiente porque o sinalizador booleano 'waitForCustomerUserId' é armazenado nas Preferências Compartilhadas do Android.

Código de exemplo

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

Se você iniciou o SDK a partir de uma classe 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

Somente chame 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.

Ativação do modo de depuração

OPCIONAL
Você pode ativar os registros de depuração chamando setDebugLog:

AppsFlyerLib.getInstance().setDebugLog(true);

AppsFlyerLib.getInstance().setDebugLog(true)

📘

Observação

Para ver os logs de depuração completos, certifique-se de chamar setDebugLog antes de invocar outros métodos do SDK.

Veja o exemplo.

🚧

Aviso

Para evitar o vazamento de informações confidenciais, verifique se os registros de depuração estão desativados antes de distribuir o aplicativo.

Testando a integração

OPCIONAL
Para obter instruções detalhadas sobre testes de integração, consulte o Guia de testes de integração do SDK para Android.

Atualizado cerca de 2 meses atrás