Troubleshooting and FAQs

Q. How to enable MoEngage SDK's debug logs for un-signed/debug builds?

To enable MoEngage SDK's debug log enable the log state in the MoEngage initializer object

MoEngage moEngage =
        new MoEngage.Builder(this, "XXXXXXXXXX")
            .setLogLevel(Logger.VERBOSE)
            .build();
    MoEngage.initialise(moEngage);

Q. How to enable MoEngage SDK's debug logs for signed builds?

To enable MoEngage SDK's debug log enable the log state in the MoEngage initializer object

MoEngage moEngage =
        new MoEngage.Builder(this, "XXXXXXXX").
            .setLogLevel(Logger.VERBOSE)
            .enableLogsForSignedBuild()
            .build();
    MoEngage.initialise(moEngage);

❗️

Make sure the above lines are removed before the application is pushed to production.

Q. Cannot see data on the dashboard?

A. If you don't see data on dashboard check if you have implemented below steps correctly

  • See if you have implemented life cycle callbacks as mentioned SDK Initialization.
  • Once you have implemented lifecycle callbacks check if you are tracking events and user attributes as mentioned Track Event
  • After that close the App. You will now see the data on the dashboard.

Q. Why add lifecycle callbacks?

A. For tracking events and attributes, SDK relies on lifecycle callbacks of Activity been tracked. This helps SDK to determine the best time to send back to MoEngage Servers without affecting apps performance.

Q. When do we update location?

A. We update User location on App launch or during Silent Pushes

Q. Blank Push Notifications?

A. Blank push notifications can come up because of the following reasons :

  1. Push from multiple servers not handled : Blank push notification if you don't handle push received from different servers correctly. Make sure the app does not try show notification if the notification is from MoEngage. Refer to Using your own listener service GCM or Using your own listener service FCM based on the library you are using.

  2. Custom Handling of notification : In case the app is doing some custom handling of notification make sure that silent push(used for uninstall ) is handled by the app. Refer to Uninstall Tracking to know more.

Q. How to delete a notification from inbox?

A. To delete a notification from Inbox refer Notification Center

Q. Why are multiple notifications shown for one campaign?

A. Multiple Notifications can show up only if both the App and MoEngage SDK try to display the notification. If the payload is from MoEngage the App should pass the payload to the MoEngage SDK and not take any other action on it.

Your push receiver should be as follows

public class FireBaseMessagingListenerService extends FirebaseMessagingService {
  @Override public void onMessageReceived(RemoteMessage remoteMessage) {
    if (remoteMessage != null){
      Map<String, String> pushPayload = remoteMessage.getData();
      if (MoEngageNotificationUtils.isFromMoEngagePlatform(pushPayload)){
        PushManager.getInstance().getPushHandler().handlePushPayload(getApplicationContext(), pushPayload);
      }else {
        //your own logic
      }
    }
  }

Refer to Configuring GCM or Configuring FCM for more details.

Q. Events visible in the Test environment but not on Live?

A If the data is visible on the Test environment and not in the Live environment, most likely you are using a test/debug build.
The SDK detects whether the build is a debug/test build or a signed build. Based on the type of build data is sent to the respective environment.

Test/Debug Build --> Data flows to Test environment
Signed/Live Build --> Data flows to Live environment.

Q. How to fix multiple receivers?

A Multiple receivers is the scenario where the manifest contains multiple services with the below intent filters:
com.google.android.c2dm.intent.RECEIVE or com.google.android.gms.iid.InstanceID in case of GCM
com.google.firebase.MESSAGING_EVENT or com.google.firebase.INSTANCE_ID_EVENT in case of FCM
Ideally your manifest file should contain only one service with the above intent filters. To know more regarding the configuration refer to this Configuring GCM or Configuring FCM based on the library you are using.

Q. Why sending push failed?

A Sending push can fail because of the following reasons :

  1. No Active device token - Push token not passed to MoEngage SDK or refresh token not passed, refer this link to see how to pass push token.

  2. Not Registered - The application has been uninstalled hence cannot send push. Please re-install the application and try.

  3. Mismatch Sender Id - The sender id and Server key provided are from different GCM/FCM projects. Please check the sender id and Server key. In case of a FCM project sender-id is part of the google-services.json file.

  4. Invalid Registration - The format of the push token passed is not correct. Please check the token passing logic.

  5. Authentication Exception - IP whitelisting is enabled for the GCM/FCM project. Please whitelist our IPs mentioned here to send push.

Q. Why push is not visible even after it was successfully sent?

A Below are the possible reasons for push not being shown even after it was successfully sent :

  • Push Payload not passed to MoEngage - This can happen when the app has its own push receiver and has not passed the payload to the MoEngage SDK. Refer to the documentation to know more about how to pass the payload.

  • Internet Connectivity - Please check your internet connectivity on the device. We would recommend you to toggle the network connection once and try.

  • Device-Specific Issue - Some of the OEMs force stop the app when the application is removed from the recent/overview screen. Please ensure the application is running in the background.

  • Build does not belong to the correct environment - The SDK detects whether the build is a debug/test build or a signed build. Based on the type of build data is sent to the respective environment.

  • Small icon not added - To post a notification small icon is mandatory. Please make sure you have added the meta-data required for push notification. Refer to the documentation for more details.

Test/Debug Build --> Use Test Environment to send notifications to your device.
Signed/Live Build --> Use Live Environment to send notifications to your device.

Q. Why push is visible but click are not recorded?

A Below are the reasons for click event not being recorded with MoEngage :

  1. Push Payload not passed to SDK - The push payload is consumed by the application and the application takes care of showing push. Refer to Passing payload in GCM or Passing payload in FCM based on the type of library you are using to pass payload to MoEngage SDK.

  2. Data not synced to MoEngage Server - Click attribution data would be sent to the MoEngage server only when the application is sent to the background. Please make sure that the application is sent to the background and wait for a couple of minutes.

Q. How to opt-out of IMEI tracking?

A In SDK version 8.5.00 and below IMEI is tracked by default by the SDK.
Due the change in the Play Store policy IMEI should not be tracked without the user's consent, Please add the below-mentioned opt-out in the onCreate() of the Application class.

MoEHelper.getInstance(getApplicationContext()).optOutOfIMEICollection(context, true)

For SDK version 9.0.00 and above IMEI is not tracked by default. In case you want the SDK to track it you need to opt-in. Refer to the API reference for more details on how to opt-in.

Q. Why we recommend MoEngage should handle push registration?

A Push token registration is a very important for sending push notifications.
Push registration consists of two things - Token Registration and Refreshing Token
Token registration can fail due to poor internet connection or null returned by the registration API. In such cases, one should retry registering for push after an exponential back off time rather than waiting for next app open.
Refresh Token can be missed out because of some OEM level customisations. Many Chinese OEMs force stops the app once it is removed from the recents. This results in missing token refresh callbacks.
MoEngage SDK has fallbacks to overcome the above issue. Hence, we suggest using MoEngage's Push Registration mechanism.
MoEngage SDK provides a callback using which the app can get the push token. Refer to Push Registration by MoEngage for more details.

Q Android Vitals says MoEAlarmReceiver is causing excessive wake-ups. Why is MoEngage using Alarms and waking up devices?

A Android Vitals report all alarms used by the app. Generally alarms are used to trigger background tasks like download/upload data to the server, which wakes up the CPU if the device is in idle state and causes battery drain.
MoEngage SDK's MoEAlarmReceiver is used to send tracked events and attributes to the MoEngage Server. This alarm is triggered within 3-5 seconds after the application goes to background. Since the CPU does not sleep so quickly no additional battery drain is done here.
Our SDK intentionally delays this sync by 3-5 seconds to ensure data accuracy due to certain customisations done by OEMs without the delay data accuracy becomes a problem.

Q. How to get extras from after redirection?

A All the extra parameter passed along while campaign creation will be a part of the bundle extras if the activity is inflated via activity name. If the activity is inflated via deeplink url all extras will be a part of the query params of the URL.

Q. How does the SDK decide whether data should be sent to Test/Live Environment?

A SDK detects the build type of the installed application and basis that it decides whether data should be sent to the Test/Live Environment of the MoEngage Platform.

Build TypeEnvironment
DebugTest
SignedLive