Android Native Integration Validation

Overview

The Integration Validation feature simplifies the integration of the MoEngage Android SDK with your intended application by providing an interface to validate Android SDK feature implementations directly via the MoEngage dashboard.
Developers often encounter challenges in implementing Android SDK features due to complex steps or misinterpretations of requirements. For instance, while configuring push notifications, they might overlook a few critical settings, such as rich notifications.
This feature enables developers and marketers to test and validate implementations independently, ensuring accuracy and reducing dependency on support teams. It enhances the integration process, minimizes errors, and ensures seamless marketing communications and user engagement.

Scope

The integration validation feature helps validate the following features:

• Data Tracking
• Push Notifications
• Push Templates

With integration validation, you cannot validate the following features:

• In-App Messaging
• Cards
• Push
  • Location Triggered Push
  • Push Notification Centre
  • Push Amplification
  • HMS Push
• Data
  • Custom attribute: Validation of the name, syntax, and data type of attribute names and their values is outside the scope.
  • Custom events: Validation of the name, syntax, and data type of the event names, event attribute names, and their values is outside the scope.

Prerequisites

The integration validation feature supports all SDK versions released after 13.4.00.

Register a Device for Integration Validation

Perform the following steps to register your device for integration validation:

1. In the left navigation menu on the MoEngage dashboard, click Test & Debug, and then click Integration validation.
2. On the Integration Validation page, scan the QR code using any QR reader app on your mobile device to register your device.
3. Select Click here on the landing page to proceed and you can select your application from the suggested apps.
   • To see your preferred application, ensure it has the correct SDK version, that is, versions including and above 13.4.00.
   • The MoEngage system displays the system Debugger page, and the app is in debugger mode and ready to be validated.

   Debugger Mode Error Paths

   Following are the reasons you are unable to see the system Debugger page on your preferred app:
   • You have scanned the wrong dashboard.
   • You have scanned the test environment of the dashboard.
   • You have set an incorrect app ID or data center (DC). For more information, see here.
4. After you register your device, the MoEngage system loads the Session Logs on the MoEngage dashboard.
5. You can open your intended app and refresh the session logs by clicking the refresh icon . Here, you can view the information associated with your session. The SDK Logger feature allows you to view the raw data associated with the sessions. For more information, see here.

   Field	Description
   Session Details	Specifies the device ID, the starting date, and the time of the session.
   Device Name	Specifies the device name.
   Status	Specifies the status of the session: Live: The session is live, and you can view the time left before the session expires. It allows you to validate the integration. Timed out: The session is expired. You can view the session details but can not perform any validating actions for the same

   If you have just installed the application, the MoEngage system requires a buffer period of approximately 5 minutes to retrieve user device details.

6. You can click the relevant session to open the associated session page.

Integration Validation Session

1. On the session page, you can view the user details associated with the live session by clicking User Info. This redirects you to the User Profile page.
2. Click Activity Info to get a detailed overview of all events the current user has performed.
   The User Info and Activity Info tabs provide details about the current session user, not the dashboard user.

3. On the session page, you will get the following information:

Device Info

Field	Description
OS Version	Specifies the operating system version of the device.
API level	Specifies the Android API level of the device.
Model Name	Specifies the model name of the user device.
Manufacturer	Specifies the device’s manufacturer.
Google Advertising Identifier (GAID)	Specifies the unique identifier for advertising on the device. For more information, see here.
Device Density	Specifies the screen density of the device.
Device Width	Specifies the width of the device screen in pixels.
Device Height	Specifies the height of the device screen in pixels.
Network Type	Specifies the type of network the device is connected to (for example, Wi-Fi, mobile data).
Device Timezone	Specifies the timezone set on the device.
App version	Specifies the version of the app installed on the device.
FCM Push token	Specifies the Firebase Cloud Messaging (FCM) token for push notifications. For more information, see here.
Push permission	Specifies whether push notification permissions are enabled on the device.

SDK Config

Field	Description
SmallIcon	Specifies whether the small icon displayed in the notification bar is configured.
largeIcon	Specifies whether the larger icon displayed within the expanded notification view is configured.
notificationcolor	Specifies whether the color is configured for the notification icon or background.
isMultipleIntegrationInDrawerEnabled	Specifies whether multiple integrations are enabled in the drawer.
IsBuildingBackStackEnabled	Specifies whether the back stack is built for navigation.
isLargeIconDisplayEnabled	Specifies whether the large icon is displayed in the notification.

Modules Integrated

You can view all modules that are integrated as part of this implementation in the Modules integrated section.

Modules	Version
moe-android-sdk	13.05.01
core	7.5.0
cards-core	2.3.1
cards-ui	2.4.1
encrypted-storage	2.1.0
geofence	4.2.1
pushbase	8.3.0
rich-notifications	5.1.0
pushkit	5.1.1
moe-push-firebase	7.2.0
inapp	8.7.0
inbox-core	3.2.1
inbox-ui	3.2.1
integration-verifier	5.3.1
pushAmp	5.2.1
realtime-trigger	3.4.1
sdk-debugger	1.2.0
security	3.2.0
trigger-evaluator	1.3.0
richNotification	5.1.1

Validation Steps

The Not Received status might be due to insufficient log generation. In such cases, try performing the action again or switching the app between background and foreground modes. If the status remains Not Received, it indicates a validation failure. Refer to the step-specific error paths for resolution.

You can view the following statuses to track the progress of each validation step:

Status	Description
Not started	Indicates that the validation for this step is not initiated.
Processing	Indicates that an action is performed on the app to track the steps. Wait for the timer to complete so you can view the outcome.
Validated	Indicates that the validation for this step is complete.
Not received	Indicates that the expected data or response is not received.
Failed	Indicates that the validation for this step is unsuccessful. For your reference, this article lists all possible error paths for each validation step.

Data Tracking

Data Tracking consists of five validation steps where you can validate the custom attribute and custom events in your intended app. To validate data tracking, expand the Data tracking drop-down list and do the following:

Custom Attribute

Custom Attribute helps you verify the tracking of custom attributes, such as confirming your preferred language, address, and membership status. Custom Attribute also ensures that the MoEngage system captures user-defined data points accurately.

To validate the custom attribute, perform the following steps:

1. Open the intended app and set a custom attribute on the app.
2. After you have setup the custom attribute, click Yes, I performed the action.
   There is a 60-second waiting period, where the MoEngage system verifies the action in the backend.
3. After the verification is completed, the status changes from Not Validated to Validated.
4. If there’s any error in the implementation, the status changes from Not Validated to Not Received. In that case, the following errors might have occurred.

Custom Attribute validation Error Paths

Status	Condition	Next Action
Not Received	If you have not performed the required action in the application, complete the action to enable tracking.	Verify your implementation of custom attributes. For details on tracking custom attributes, see here.
	If you have performed the action and the status is not updated, custom attribute tracking might not be integrated.

Custom Event

Custom Event helps you verify the tracking of user-defined interactions, such as button clicks or video plays, are recorded accurately. For example, Ensuring a Product Added to Cart event is tracked with the correct product ID.

To validate the custom attribute, perform the following steps:

1. Open the intended app and set a custom event on the app.
2. After you have setup the custom attribute, click Yes, I performed the action.
   There is a 60-second waiting period, where the MoEngage system verifies the action in the backend.
3. After the verification is completed, the status changes from Not Validated to Validated.
4. If there is any error in the implementation, the status changes from Not Validated to Not Received. In that case, the following errors might have occurred:

Custom Event Validation Error Paths

Status	Condition	Next Action
Failed	Custom event is not tracked (Android Native).	Ensure that the TrackEvent method is called with the custom event.
Failed	Custom event is not tracked.	The TrackEvent method is called before SDK initialization. Initialize the SDK first.

GAID Tracking

GAID Tracking helps ensure the unique advertising identifier is captured and transmitted accurately for targeted advertising or analytics. GAID Tracking involves inspecting device logs and validating integrations with advertising platforms.
The status is automatically displayed as Validated for GAID Tracking based on the device settings.

GAID Tracking Validation Error Paths

Status	Condition	Next Action
Not Received	The Google Ads library is missing.	Add the Google Ads library to the integration. For more information, see here.
	The enableAdIdTracking() method was not called.	Add the method call to enable AD ID tracking. For more information, see here.

Login

Login helps ensure user authentication events are accurately recorded in logs or analytics systems. Login includes validating event triggers, user data, and session creation.

To validate the login, perform the following steps:

1. Login to the intended app.
2. After you have logged in, click Yes, I performed the action.
   There is a 60-second waiting period, where the MoEngage system verifies the action in the backend.
3. After the verification is completed, the status changes from Not Validated to Validated.
4. If there is any error in the implementation, the status changes from Not Validated to Not Received. In that case, the following errors might have occurred.

Login Validation Error Paths

Status	Condition	Next Action
Failed	Login method was not called.	Call setUniqueId in the code. For more information, refer to Track User Attributes.

Logout

Logout helps ensure that user sign-out events are logged correctly and sessions are invalidated. Logout involves testing log entries, session cleanup, and API responses.

To validate the logout, perform the following steps:

1. Log out of the intended app.
2. After you have logged out, click Yes, I performed the action.
   There is a 60-second waiting period, where the MoEngage system verifies the action in the backend.
3. After verification is completed, the status changes from Not Validated to Validated.
4. If there is any error in the implementation, the status changes from Not Validated to Not Received. In that case, the following errors might have occurred.

Logout Validation Error Paths

Status	Condition	Next Action
Failed	Logout method was not called.	Ensure the logout method is invoked. For more information, refer to Track User Attributes.

Push

Push consists of two sections:

• Basic Push
• Push Templates

Basic Push

Basic Push consists of six validation steps where you can validate the configuration of small app icon, large app icon, push permission, and notification in various app states. To validate Push, expand the Basic Push drop-down list and do the following:

Small App Icon

Small app icon helps you verify that the small app icon is displayed correctly within the notification area across various devices. For example, small app icon ensures that the icon appears crisp, aligns with branding guidelines, and scales appropriately without distortion.
The status is automatically displayed as Validated for small app icon based on the device configurations.

Small App Icon Validation Error Paths

Status	Condition	Next Action
Failed	small app icon is not configured.	Add NotificationConfig during SDK initialization and include a small icon. For more information, refer to Push Configuration.
Failed	small app icon is not visible as expected.	Add a new small icon that adheres to the small icon guidelines. For more information, refer to Push Configuration.

Large App Icon

Large app icon helps you verify that the large app icon is displayed as intended when the notification is expanded. For example, ensuring the icon enhances the notification’s visual appeal while maintaining clarity and adhering to size requirements.
The status is automatically displayed as Validated for large app icon based on the device configurations.

Large App Icon Validation Error Paths

Status	Condition	Next Action
Failed	Large app icon is not configured.	Add NotificationConfig during SDK initialization and include a large icon in the parameter. For more information, refer to Push Configuration.

Push Permission

Push permission helps you verify that the app requests push notification permissions from the user in a seamless and user-friendly manner. For example, ensuring the permission prompt is triggered appropriately and aligns with the app’s flow.

To validate the push permission, perform the following steps:

1. Open the app and perform the action to trigger the notification runtime permission and accept the request.
2. After you have accepted the request, click Yes, I performed the action.
   There is a 60-second waiting period, where the MoEngage system verifies the action in the backend.
3. After the verification is completed, the status changes from Not Validated to Validated.
4. If there is any error in the implementation, the status changes from Not Validated to Not Received. In that case, the following errors might have occurred.

Push Permission Validation Error Paths

Status	Condition	Next Action
Failed	Failed to ask permission from the user. Dialog didn’t show up.	Ask for push permission from the user at runtime. For more information, refer to Notification Runtime Permissions.
Failed	Dialog was shown, but push permission is still not updated.	Inform the SDK whether the user granted/denied permission. For more information, refer to Notification Runtime Permissions.
Failed	User denied the push permission dialog; the dialog no longer shows up.	Redirect the user to the settings page to request permission manually. For more information, refer to Notification Runtime Permissions.

Test Push with App in Foreground

Test push with app in foreground helps you verify that push notifications are received and rendered properly when the app is open and in use. For example, ensure notifications do not disrupt user activity while displaying them subtly but noticeably.

To validate the push notification with the app in the foreground, perform the following steps:

1. Open the intended app in the foreground state.
2. Click Send test push on the dashboard.
   There is a 60-second waiting period, where the MoEngage system verifies the action in the backend.
3. Click Confirm app in foreground to validate the step if the app was in the foreground when the notification was received. If not, click Reset to start validating again.
4. After the verification is completed, the status changes from Not Validated to Validated.
5. If there’s an error in the implementation, the status changes from Not Validated to Not Received. In that case, the following errors might have occurred.

Test Push with the App in Foreground Validation Error Paths

Status	Condition	Next Action
Failed	Push notification not shown.	No Firebase service is added to handle the MoEngage payload. Add the MoEngage Service file. For more information, refer to Push token registration and display.
Failed	Push notification not shown.	The custom service file didn’t pass the payload to the SDK. For more information, refer to Push token registration and display.
Failed	Push notification not shown.	App created the notification but didn’t inform the SDK. For more information, refer to Push Display Handled by Application.

Test Push with App in Background

Test push with app in background helps verify that push notifications are delivered and displayed correctly when the app runs in the background. For example, test push with app in background ensures that the notification appears in the notification center with accurate content and icons.

To validate the push notification with the app in the foreground, perform the following steps:

1. Open the intended app in the background state.
2. Click Send test push on the dashboard.
   There is a 60-second waiting period, where the MoEngage system verifies the action in the backend.
3. Click Confirm app in background to validate the step if the app was in the background when the notification was received. If not, click Reset to start validating again.
4. After the verification is completed, the status changes from Not Validated to Validated.
5. If there is any error in the implementation, the status changes from Not Validated to Not Received. In that case, the following errors might have occurred.

Test Push with the App in Background Validation Error Paths

Status	Condition	Next Action
Failed	Push notification not shown.	No Firebase service is added to handle the MoEngage payload. Add the MoEngage Service file. For more information, refer to Push token registration and display.
Failed	Push notification not shown.	The custom service file didn’t pass the payload to the SDK. For more information, refer to Push token registration and display.
Failed	Push notification not shown.	App created the notification but didn’t inform the SDK. For more information, refer to Push Display Handled by Application.

Test Push with App in Killed State

Test push with app in killed state helps you verify that push notifications are successfully delivered even when the app is closed or not running. For example, ensuring that the notification alerts the app correctly when interacted with, providing a seamless user experience.

To validate the push with the app in the killed state, perform the following steps:

1. Kill the app by swiping it away from the open applications list on your device.
2. Click Send test push on the dashboard.
   There is a 60-second waiting period, where the MoEngage system verifies the action in the backend.
3. Click Confirm app in killed state to validate the step if the app was in the killed state when the notification was received. If not, click Reset to start validating again.
4. After the verification is completed, the status changes from Not Validated to Validated.
5. If there is any error in the implementation, the status changes from Not Validated to Not Received. In that case, the following errors might have occurred.

Test Push with the App in Killed State Validation Error Paths

Status	Condition	Next Action
Failed	Push notification not shown.	No Firebase service is added to handle MoEngage payload. Add the MoEngage Service file. For more information, refer to Push token registration and display.
Failed	Push notification not shown.	Custom service file didn’t pass the payload to the SDK. For more information, refer to Push token registration and display.
Failed	Push notification not shown.	App created the notification but didn’t inform the SDK. For more information, refer to Push Display Handled by Application.
Failed	Push notification not shown.	Initialize the SDK in the onCreate() method of the application class. For more information, refer to SDK initialization.
Failed	Push notification not shown.	Third-party library failed to pass the payload to the SDK. Check if the library works as expected in a killed state.

Push Templates

Push Templates consists of two validation steps where you can validate the exact alarm permission and integration of the push template. To validate Push Templates, expand the dropdown and do the following:

Test Push Templates

Test push templates helps you validate the structure and content of push notification templates before deployment. For example, Test push templates ensures that all required fields are correctly configured, reducing errors and improving the user engagement experience.

To validate the push templates, perform the following steps:

1. If validated, click Send test push to initiate the notification.
2. After the notification is sent, wait 60 seconds for interactions to be tracked.
3. On receiving the notification in the app:
   • If you see an image banner template, click Yes, notification has image banner to validate.
   • If you see a basic template, click No, notification has basic template.

Test Push Templates Validation Error Paths

Status	Condition	Next Action
Failed	Basic push notifications are showing.	Push Templates Library is not integrated with the app. For more information, refer to Push Templates.
Failed	Basic push notifications are showing.	If Library is added, check for network issues; change the network and retry.
Failed	Push notification has white/black system boundaries on some devices, fully covered on others.	This is an expected behavior change from Android 12.

Timer Exact Alarm Permission Set or Not

Timer exact alarm permission validation helps you verify whether the timer’s exact alarm functionality is configured. For example, ensuring precise triggering of alarms in time-sensitive scenarios, enhancing user reliability and scheduling accuracy.

To validate the Timer exact alarm permission, perform the following steps:

1. Integration status is automatically validated.
2. If validated, click Send test push. The notification will be attempted.
3. If successfully attempted, wait 60 seconds for interaction tracking.
4. Check if the notification displays the Timer with the Progress Bar template:
   • If yes, click Yes, notification has Timer with progress bar.
   • If no, and the basic template is shown, click No, notification has basic template.

Timer Exact Alarm Permission Set Validation Error Paths

Status	Condition	Next Action
Failed	Progress bar not showing in push notification	Forgot to add the permission. For more information, refer to Push Templates
Failed	Progress bar not showing in push notification	Enable the permission at runtime by the user. For more information, see Push Templates.