Troubleshoot Issues on Android Apps

This guide provides detailed solutions to common problems that occur when implementing the MobilePush Android SDK in your app.

If you encounter issues receiving messages in your app, consider the following troubleshooting steps.

Check the SDK’s log output
Send a test push
Evaluate the SDK state

Enable logging in the SDK and verify no errors are being logged.

Ensure you attempt this important debugging step. The SDK provides verbose messages that are helpful in identifying and rectifying errors.
To capture the log output from MobilePush SDK, add the MCLogListener interface.
Implement a custom log listener.

To test whether your device can receive a push directly from FCM, follow these steps.

Get the push token from the SDK
Use the following script to send yourself a push message.

If your device successfully receives a message using the sample script but still can’t receive a message from Marketing Cloud Engagement, follow these steps.

Wait 15 minutes after the first registration call for the device you’re testing with to ensure your device is properly registered in Engagement.
Check the List you created in the Engagement UI and ensure the DeviceId you printed in Logcat shows up in the list.

Look through the output from the SDK's getSdkState() method.

Although this method provides extensive information, when you're debugging push messaging, focus your attention on the NotificationManager and PushMessageManager sections for key insights.

If you've implemented multiple push providers, review Troubleshoot Multiple Push SDKs for more information.

The InitializationStatus is provided via the InitializationListener passed into the call to the SFMCSdk’s configure method.

The InitializationStatus is provided via the InitializationListener passed into the call to the MobilePush SDK's init method. While this class contains extensive information that can help troubleshoot SDK initialization issues, there are only a limited number of things that you can address at runtime.

This section describes the methods from InitializationStatus that are useful to check at runtime and how you can recover from them. The InitializationStatus is provided via the InitializationListener passed into the call to the SFMC SDK's configure method.

isUsable(): Use isUsable() if all you want to know is whether the SDK is in a “usable” state. The term “usable” here simply means that the SDK’s initialization didn’t fail. However, there could be other issues you must address.
status(): The status() method returns the status of the initialization call.
locationsError(): If you’ve configured the SDK to enable either geofence or proximity messaging, locationsError() indicates whether the SDK encountered an issue with the Google Play Service location library. Additionally, you can also use playServicesMessage() and playServicesStatus() to determine the exact action that you must take to resolve this issue. However, the most likely issue is that the device doesn’t have a compatible version of Google Play Services installed and you must prompt the user to perform an update.
messagingPermissionError(): messagingPermissionError() indicates that region messaging was unable to be turned on after a restart due to the android.Manifest.permission.ACCESS_FINE_LOCATION or android.Manifest.permission.ACCESS_BACKGROUND_LOCATION no longer being granted. Enabling geofence or proximity messaging requires you to request the runtime permission for location. Then, after you've called the corresponding messaging enablement method (enableGeofenceMessaging or enableProximityMessaging), the SDK will track this setting and check whether the permission is still granted during each initialization. If the user has revoked the location permission from your application, the SDK disables the previously enabled messaging type and requires you to re-request the permission from the user, and re-enable messaging in the SDK.

While you can integrate multiple push SDKs into a single app, this approach can lead to complications and we can't guarantee reliable results. The following sections highlight some considerations you must keep in mind as you develop your app with multiple push SDK integrations. Areas of concern can include registration, geolocation, and more.

Any other push provider you choose must also allow a multiple push provider implementation.

Don’t set the SenderId during the SDK’s initialization.

If the SenderId is set during initialization, the SDK attempts to fetch a push token from the Firebase SDK. Doing so can lead to inconsistencies in the token that is registered with Engagement.

Set the push token in the SDK whenever it has been retrieved or updated from the Firebase SDK.

Not updating the SDK with a new push token when onNewToken is triggered prevents Engagement from sending push messages to your application.

When a push message is received from Engagement, pass it into the SDK to be presented.

Messages passed into handleMessage that aren’t from Engagement are ignored.