Android AI-Assisted Integration

Purpose

This runbook helps an AI coding agent integrate the Reteno Android SDK into a native Android application and validate that the integration works correctly.

The agent must not stop after applying code changes. The integration is complete only when the required validation checks pass or a blocker is clearly documented.

Agent Role

You are an AI coding agent responsible for integrating the Reteno Android SDK into an existing native Android application.

Your goal is not only to update the code, but also to validate that the SDK integration works correctly.

Quick Start Prompt

Use this Android runbook as your operating instruction.

Integrate the Reteno Android SDK from scratch into the selected native Android application.

First inspect the project and detect the Android project structure, Gradle setup, app module, package name, app entry points, Firebase setup, FCM setup, existing notification handlers, current SDK version, and existing push notification logic.

Use the official Reteno Android SDK Integration Guide as the primary source of truth for Android-specific setup:

https://docs.reteno.com/reference/android-sdk-setup

Use the official Reteno Android Push Handling Guide for FCM token handling and push notification processing:

https://docs.reteno.com/reference/android-push-handling

Do not ask for all inputs upfront. Ask only for information that cannot be detected from the codebase, Reteno MCP, or official Reteno documentation.

Before making code changes, complete the Developer Preparation Checklist. If any required preparation item is missing, document it before continuing and do not mark the integration as complete until the missing validation step is completed or clearly reported as blocked.

Preserve existing application logic. Do not overwrite Firebase configuration, FCM setup, notification handlers, app lifecycle code, authentication flow, analytics logic, or existing push notification logic.

Use the existing Android project setup. Do not switch from Gradle to another build system, change app architecture, replace Firebase setup, or update SDK versions unless the developer explicitly confirms this.

If a Reteno SDK access key is provided, use it through the approved project configuration method. Do not leave SDK key placeholders in the final code.

Do not hardcode secrets, Firebase keys, service account data, or other sensitive values in committed files.

Use the selected test environment confirmed by the developer. This can be an Android emulator, physical Android device, or another supported test environment.
Before starting code changes, run a pre-flight check.
Before runtime validation, complete the Local Device Automation / mobile-mcp Quick Check. If mobile-mcp is unavailable, ask the developer to perform runtime actions manually and continue Reteno MCP validation after confirmation.

Confirm:

• a temporary local branch is created;
• the Reteno SDK access key is available through the approved project configuration method;
• Reteno MCP is connected and available for Reteno validation;
• device/emulator automation tooling is available if the agent is expected to run the app or interact with the device;
• the selected Android emulator or physical device is available;
• the developer can manually run the app, grant notification permission, and open the test push if automation is unavailable.

If any required pre-flight item is missing, document it before continuing.

Continue with code integration only if the missing item does not block code changes.

Do not mark the integration as complete until runtime and MCP validation are completed.

After applying SDK changes, attempt to build and run the application.

If build/run fails, do not repeat the same failed action without a new hypothesis. Continue safe diagnostics while distinct testable causes remain. Escalate when the issue requires local environment access, external access, credentials, signing, dashboard changes, GUI interaction, local automation, or manual device actions.

Do not stop after code changes.

If the developer asks to skip build/run or MCP validation, return a partial report, not a complete integration report.

The report must clearly state:

• which steps were completed;
• which validation steps were skipped;
• who requested the skip;
• which blockers remain;
• what must be done to resume validation.

Do not mark the integration as complete if build/run or MCP validation was skipped.

Before MCP-based validation, verify that Reteno MCP is connected in the same environment where you are running.

After the app builds and runs, validate the integration through Reteno MCP:

• find the contact;
• verify mobilePushToken;
• identify token type: FCM;
• send a test push;
• verify DELIVERED;
• verify CLICKED after the push notification is opened.

Validate every Reteno SDK feature that you integrate, modify, or are explicitly asked to verify.

At minimum, for mobile push integration, validate contact creation, mobilePushToken, token type, test push, DELIVERED, and CLICKED.

Run feature-specific validation when the current integration task includes additional SDK features such as In-App messages, custom events, deeplinks, custom push data, or externalCustomerId.

If a step cannot be completed programmatically, ask for the required manual action and continue after confirmation.

If an MCP capability is unavailable, document it as a missing MCP capability and continue with the remaining validation steps where possible.

Return the final report using the format defined in this runbook.

Do not mark the integration as complete until the required validation checks pass or a blocker is clearly documented.

Source of Truth

Use only official Reteno sources and the current customer application codebase for Android SDK integration.

Note — Reteno MCP: Reteno MCP must be connected in the same environment where the AI coding agent runs. Use Reteno MCP for actions such as reading contacts, checking mobile push tokens, sending test pushes, and verifying statuses.

Note — Reteno llms.txt: Reteno llms.txt is a documentation index for AI agents. Use it to find the latest Reteno documentation pages, SDK guides, and API references. It does not replace Reteno MCP validation.

Agent Behaviour Rules

Follow these rules throughout the Android SDK integration:

• Inspect the project before making any code changes.
• Detect the Android project structure, package manager, app module, current SDK version, Firebase setup, push notification setup, and notification handlers from project files whenever possible.
• Ask the user only for information that cannot be detected from the project, Reteno MCP, or official Reteno documentation.
• Use the existing project setup. Do not switch package managers, app architecture, Firebase setup, push provider, or SDK versions unless the user explicitly confirms this.
• Preserve existing application logic.
• Do not overwrite existing Firebase configuration, notification handlers, app lifecycle code, authentication flow, analytics logic, or existing push notification logic.
• Do not hardcode secrets, credentials, SDK access keys, Firebase keys, service account data, or other sensitive values in public files.
• If a step cannot be completed programmatically, ask the developer to complete it manually.
• After applying code changes, continue validation.
• Use Reteno MCP for validation only after confirming that the required MCP capability is available and authorized in the current environment.
• Do not report the integration as complete until all required validation checks pass or a blocker is clearly documented.
• If validation fails, identify the failed step, troubleshoot, retry safe fixes, and document unresolved blockers in the final report.
• If build/run is blocked by an issue unrelated to Reteno SDK integration, apply only the smallest safe fix required to unblock runtime validation. Document the issue, explain why it was unrelated to Reteno, list the files changed, and report the fix in the final report.
• Ask for developer confirmation before applying a fix that changes app behavior, package identity, SDK requirements, product compatibility, signing, Firebase configuration, or Reteno dashboard configuration.
• If the repository contains local agent instructions, such as CLAUDE.md, Cursor rules, or similar files, inspect them before making changes. If they conflict with this runbook, ask the developer to confirm which instruction has priority.

Android Project Detection

Use this runbook only for native Android applications.

Use this Android SDK flow when the project contains Android-specific files or configuration, such as:

• build.gradle;
• build.gradle.kts;
• settings.gradle;
• settings.gradle.kts;
• AndroidManifest.xml;
• MainActivity;
• MainApplication;
• custom Application class;
• google-services.json;
• Android source folders such as app/src/main;
• Firebase Messaging service;
• notification receivers, services, or handlers.

Before making changes, detect:

• Android project structure;
• app module name, for example app;
• package name / applicationId;
• Gradle setup: Groovy or Kotlin DSL;
• Kotlin or Java usage;
• current Reteno SDK usage, if any;
• Firebase / FCM setup;
• existing push notification setup;
• existing notification handlers;
• existing custom Application class;
• existing deeplink intent filters;
• existing WorkManager configuration, if present.

Do not use this native Android runbook directly for React Native, Flutter, Expo, Ionic, Cordova, or Unity projects.

If the project is cross-platform, use the corresponding cross-platform runbook first and apply native Android steps only when that runbook or project setup requires native Android changes.

Required Inputs

Ask the developer only for information that cannot be detected from the project files, Reteno MCP, or official Reteno documentation.

Before asking the developer, inspect the project and detect:

• app module name;
• package name / applicationId;
• Gradle setup;
• Kotlin or Java usage;
• current Reteno SDK version, if installed;
• Firebase / FCM configuration;
• google-services.json;
• custom Application class;
• AndroidManifest.xml;
• existing notification handlers;
• existing push token handling;
• existing deeplink handling;
• existing WorkManager configuration, if present.

Required for Android SDK integration

Ask for these values only if they are missing, unclear, or cannot be detected automatically:

• Reteno SDK access key or approved project configuration method for providing it;
• Reteno app or environment name;
• environment type: development, staging, or production;
• Android package name / applicationId, if it cannot be detected from the project;
• confirmation that the selected Reteno mobile app should be used for the current validation run;
• confirmation that the selected Reteno mobile app is configured for Android / FCM;
• confirmation of which SDK features must be enabled:
  • mobile push;
  • custom events;
  • user identification;
  • In-App messages, if included in scope.

Required for Android push setup and validation

• confirmation that Firebase / FCM is configured for the selected Android app;
• confirmation that google-services.json belongs to the correct Firebase project;
• confirmation that the mobile app is configured in Reteno with FCM token type;
• confirmation that Reteno MCP is connected and available in the AI coding agent environment;
• confirmation that the signed-in Reteno account has access to the selected Reteno app/environment;
• access to the selected test environment for push validation: Android emulator, physical Android device, or another supported environment;
• confirmation from the developer that push validation is supported in the selected test environment;
• confirmation that push notifications can be enabled in the selected test environment;
• confirmation that the developer can open the test push notification if the agent cannot interact with the environment directly.

Required for custom event validation

Ask for these inputs only when custom event validation is part of the current integration task:

• confirmation that a test custom event can be added to the app code;
• confirmation that the event name testAiEvent can be used for validation;
• access to Reteno MCP, Reteno UI, backend data, event log, or logs to verify that the event was received and assigned to the correct contact.

Required for feature-specific In-App validation

Ask for these inputs when In-App validation is part of the current integration task.

• confirmation whether the agent should use an existing In-App message or ask the developer/admin to create or configure it in Reteno UI;
• existing In-App message name or ID to use for validation, if an existing In-App message should be used;
• confirmation that the event name eventTestInApp can be used for validation;
• access to the selected test environment where the In-App message should appear;
• confirmation that the developer can open the app and interact with the In-App message if the agent cannot do it directly.

Feature-specific validation inputs

Ask for these values only when the related feature is part of the current integration task.

For externalCustomerId validation, ask for:

• login or registration flow;
• test login or registration credentials, if required;
• expected stable customer ID format.

For deeplink or custom push data validation, ask for:

• expected deeplink format;
• expected Android intent/deeplink behavior;
• expected custom push payload fields;
• expected destination screen or app behavior.

If a feature is not part of the current integration task, report it as not requested for this integration.

Security rules

Do not include credentials, Firebase keys, service account data, private keys, certificates, or other sensitive values in the prompt, public documentation, final report, or committed source files.

If a Reteno SDK access key is required, ask the developer to provide it through the approved project configuration method.

If a required input is missing, explain:

• what information is missing;
• why it is required;
• whether the integration can continue without it;
• which validation steps will be blocked until the input is provided.

Developer Preparation Checklist

Before starting Android SDK integration, ask the developer to prepare or confirm the items below.

The agent must not ask for all values upfront if they can be detected from the project. However, the developer should make sure that the required project access, credentials, environment, and validation tools are available before the integration run starts.

1. Project access

The developer should provide or confirm:

• access to the Android project repository;
• the correct branch for the integration run;
• whether the run should be done on a temporary local branch;
• whether there are local agent instructions, such as CLAUDE.md, Cursor rules, or similar files;
• app module name, if it cannot be detected automatically;
• Android package name / applicationId, if it cannot be detected automatically;
• whether the project uses Gradle Groovy DSL or Gradle Kotlin DSL;
• whether the app should be validated on an Android emulator, physical Android device, or another supported environment.

2. Reteno setup

The developer or admin should prepare or confirm:

• selected Reteno organization / workspace;
• selected Reteno mobile app for Android;
• Reteno SDK access key or approved configuration method for providing it;
• whether the selected Reteno mobile app is configured for Android / FCM;
• whether the selected Reteno app matches the Android package name / applicationId;
• whether the selected Reteno app matches the target environment: development, staging, or production;
• whether the signed-in Reteno account has access to the selected app/environment.

Do not paste SDK access keys, Firebase keys, service account data, private keys, certificates, or other secrets into public chats,
public files, or committed source files.

If the selected Reteno app label suggests another platform or outdated purpose, but the app configuration correctly accepts Android FCM tokens, do not treat this as a blocker.

Report it as a warning and recommend renaming the Reteno app for clarity.

The decisive validation criteria are:

• selected Reteno app has access to the current environment;
• token type is FCM;
• Android contact receives an FCM token;
• test push can be sent;
• DELIVERED and CLICKED can be verified.

3. Firebase / FCM setup

The developer should confirm:

• Firebase / FCM is configured for the selected Android app;
• the correct google-services.json is available in the project;
• google-services.json belongs to the correct Firebase project;
• Android package name / applicationId matches Firebase and Reteno configuration;
• the selected Reteno mobile app is configured with token type FCM;
• Firebase Messaging dependency and plugin setup are available or can be safely added;
• existing Firebase Messaging service and notification handlers should be preserved.

4. Test environment

The developer should prepare one supported test environment:

• Android emulator;
• physical Android device;
• another supported Android test environment.

The developer should also confirm:

• the app can be built in the selected environment;
• the app can be run in the selected environment;
• push notification permission can be granted;
• notification channel can be enabled;
• the developer can manually open the test push notification if the agent cannot interact with the emulator or device directly;
• the developer can provide logs if build/run fails.

If the Android emulator cannot be opened, the developer should be ready to use a physical Android device or provide Android Studio / Gradle / Logcat details.

5. Reteno MCP and local automation tools

The developer should confirm whether Reteno MCP is connected in the same environment where the AI coding agent runs.

Reteno MCP is required for Reteno-side validation:

• contact lookup;
• mobilePushToken verification;
• test push creation and sending;
• DELIVERED / CLICKED status checks.

Local device or emulator automation tooling is separate from Reteno MCP.

Local automation tooling is used for runtime interaction:

• running the app;
• granting notification permission;
• opening the test push notification.

If local automation tooling is unavailable, the developer should be ready to perform these actions manually and confirm completion.

If Reteno MCP is unavailable, Reteno-side validation cannot be completed and must be reported as blocked or pending.

If local device automation MCP is added during the current agent session, the developer may need to restart the agent environment before the tool becomes available.

6. Build and runtime logs

Do not repeat the same failed action without a new hypothesis.

Continue safe diagnostics while distinct testable causes remain.

Escalate when the issue requires local environment access, external access, credentials, signing, dashboard changes, GUI interaction, local automation, or manual device actions.

When escalation is required, ask the developer to run the app through Android Studio, Gradle, or the relevant project tool and provide:

• the exact build or runtime error;
• crash reason, if available;
• relevant logs;
• emulator or device details;
• reproduction steps.

Continue only after the developer provides the missing information or confirms the blocker.

7. Feature-specific validation preparation

If the current integration task includes custom events, the developer should confirm:

• a test custom event can be added to the Android app code;
• the event name testAiEvent can be used;
• event validation is possible through Reteno MCP, Reteno UI, backend logs, or event logs.

If the current integration task includes In-App messages, the developer or admin should confirm:

• whether an In-App message already exists or should be created;
• existing In-App message name or ID, if an existing In-App should be used;
• whether default In-App message creation is available in the selected Reteno account;
• whether the developer/admin can create, configure, publish, or confirm the In-App message manually in Reteno UI if required.

If the current integration task includes externalCustomerId, the developer should confirm:

• login or registration flow can be tested;
• test credentials are available, if required;
• expected stable customer ID format is known.

8. Pre-flight result

Before code changes start, the agent should summarize the pre-flight status:

• project access: ready / blocked;
• SDK access key handling: ready / placeholder / missing;
• Firebase / FCM setup: confirmed / needs confirmation;
• Reteno MCP: connected / unavailable;
• local device automation: available / unavailable;
• test environment: ready / unavailable;
• manual actions required from developer;
• validation steps that may be blocked.

If a required item is missing, continue only with the steps that are not blocked.

Do not mark the integration as complete until build/run and required Reteno MCP validation are completed or a blocker is clearly documented.

Android SDK Integration Workflow

Follow this workflow for native Android SDK integration.

0. Prepare a safe working branch

Before making code changes, check the current Git branch and working tree state.

For evaluation, test, or temporary integration runs:

• create and switch to a temporary local branch;
• do not make temporary integration changes directly on main or master;
• do not commit, push, or merge changes unless the developer explicitly asks for it.

If you cannot create or switch to a temporary branch, ask the developer to confirm how to proceed before modifying files.

Report the branch name and working tree state in the final report.

1. Inspect the project

Before making changes, inspect the Android project.

Identify:

• project structure;
• app module;
• Gradle setup;
• Kotlin or Java usage;
• package name / applicationId;
• AndroidManifest.xml;
• custom Application class, if present;
• existing Firebase / FCM setup;
• existing google-services.json;
• existing notification handlers;
• existing push token handling;
• existing deeplink intent filters;
• existing WorkManager setup, if present;
• files that may need to be updated.

Do not ask the developer for information that can be detected from the project files.

2. Check official Android SDK documentation

Use the official Reteno Android SDK Integration Guide as the primary source of truth for Android-specific setup:

https://docs.reteno.com/reference/android-sdk-setup

Use the Android Push Notifications Integration Guide for FCM token handling, notification events, deeplinks, custom data, and push subscription status:

https://docs.reteno.com/reference/android-push-handling

Use the Firebase Cloud Messaging setup guide when Firebase / FCM configuration needs to be verified:

https://docs.reteno.com/reference/setting-up-your-firebase-application-for-firebase-cloud-messaging

3. Check whether Reteno SDK is already installed

If Reteno SDK is already installed, do not reinstall it from scratch.

Instead:

• detect the current SDK version from Gradle files or lock files;
• check how the SDK is initialized;
• check whether FCM token handling is configured;
• check whether push notification handling is configured;
• check whether the current integration is incomplete, outdated, or misconfigured.

If Reteno SDK is not installed, continue with a new Android SDK integration flow.

4. Check SDK version and release notes

Before installing, updating, or troubleshooting the Reteno SDK:

• detect the current SDK version from project files, if installed;
• check the official SDK Release Notes;
• check whether the issue may be related to an outdated SDK version, compatibility issue, migration requirement, or known fixed issue.

Do not update the SDK automatically unless the developer explicitly asks for an update or the official documentation indicates that an update is required.

Use the latest stable Reteno Android SDK version recommended by the official documentation, SDK Release Notes, or package registry.
Do not use pre-release, beta, alpha, or release-candidate SDK versions unless the developer explicitly asks for it.

If a newer pre-release version exists, document it as available but do not select it automatically.

Report the selected SDK version and whether any pre-release version was skipped.

5. Check prerequisites

Before applying SDK changes, confirm that the required prerequisites are available.

Check or ask for:

• Reteno SDK access key or approved configuration method;
• selected Reteno app/environment;
• Android package name / applicationId;
• Firebase / FCM configuration;
• google-services.json;
• Reteno MCP access;
• selected test environment for push validation.

Before changing Android platform requirements:

• detect and report the current minSdkVersion;
• compare it with the requirements of the selected Reteno SDK version;
• do not raise minSdkVersion without explicit developer approval;
• document the compatibility impact if a change is required.

Treat a minSdkVersion increase as a product compatibility decision, not as an automatic fix.

If minSdkVersion is increased, document which Android versions are no longer supported.

If a prerequisite cannot be verified automatically, ask the developer for confirmation.

6. Apply Android SDK integration changes

Use the official Android SDK Integration Guide to apply the integration.

Depending on the project, you may need to:

• enable AndroidX, if not already enabled;
• verify Java compatibility settings;
• add Maven Central repository, if missing;
• add Reteno SDK dependency;
• add Firebase Messaging dependency, if required;
• configure or create a custom Application class;
• initialize Reteno SDK in the application startup path;
• register the custom Application class in AndroidManifest.xml;
• configure push notification permission handling;
• configure FCM token handling;
• preserve existing notification handlers and push logic.

Do not overwrite existing application logic.

Keep:

• existing Firebase configuration;
• existing notification handlers;
• existing deeplink handling;
• existing authentication flow;
• existing analytics logic;
• existing app lifecycle code;
• existing WorkManager configuration, unless a safe fix is required and confirmed.

7. Build and run the application

After applying code changes, build or run the application when possible.

If build or run fails, try to fix the issue only when it can be resolved safely through code, dependency setup, project configuration, or supported tooling.
If build/run is blocked by an issue unrelated to Reteno SDK integration, the agent may apply a safe minimal fix only when the issue prevents runtime validation.

You must:

• identify the issue as unrelated to Reteno SDK integration;
• explain why it blocks build/run;
• apply the smallest safe fix;
• preserve existing app logic;
• document the fix in the final report;
• ask for developer confirmation if the fix changes app behavior, package identity, SDK requirements, product compatibility, signing, Firebase configuration, or Reteno dashboard configuration.

Do not retry indefinitely.

After two unsuccessful attempts to fix the same build, launch, emulator, or runtime crash issue, ask the developer to run the app through Android Studio or Gradle and provide:

• the exact build or runtime error;
• crash reason, if available;
• relevant logs;
• emulator or device details;
• reproduction steps.

Continue only after the developer provides the missing information or confirms the blocker.

8. Validate the integration with Reteno MCP

After the app builds and runs, validate the integration through Reteno MCP.

Continue with the validation flow:

• find the contact;
• verify mobilePushToken;
• identify token type: FCM;
• send a test push;
• verify DELIVERED;
• verify CLICKED after the push notification is opened.

Do not report the integration as complete until all required validation checks pass or a blocker is clearly documented.

9. Troubleshoot and retry failed checks

If a build, integration, or validation check fails, do not stop immediately.

For each failed check:

1. Identify the failed step.
2. Capture the observed result, error, log, MCP response, or missing status.
3. Check official Reteno Android documentation, SDK Release Notes, mobile push error codes, MCP results, project logs, and known SDK issue references.
4. Apply a safe fix if the issue can be resolved through code, project configuration, or supported MCP actions.
5. Build, run, or validate again after applying the fix.
6. Continue the workflow if the issue is resolved.
7. If the issue requires external access, unsupported MCP action, Reteno dashboard changes, Firebase setup, credentials, or admin confirmation, ask the developer or admin to complete the required step.
8. Document all attempted fixes and remaining blockers in the final report.

Do not repeat the same fix indefinitely. If the issue cannot be resolved after a reasonable retry, document what was tried and escalate with evidence.

10. Return the final report

At the end of the integration, return a structured final report.

Include:

• detected platform;
• evidence used for platform detection;
• SDK version;
• files inspected;
• files changed;
• dependencies added or updated;
• manual steps requested;
• manual steps completed;
• build/run result;
• Reteno MCP connection;
• Reteno MCP validation results;
• unresolved blockers;
• recommended next steps.

Manual Setup Steps

Do not stop when manual interaction is required.

Before requesting manual action, check whether the step can be completed through code changes, project configuration, supported tooling, or supported MCP actions.

If you cannot complete a step programmatically, ask the developer to perform the required action, wait for confirmation, and then continue the integration or validation flow.

1. Complete project-level configuration when possible

If the project setup allows it, complete project-level configuration yourself.

For Android, this may include:

• updating Gradle dependencies;
• updating AndroidManifest.xml;
• configuring or creating a custom Application class;
• adding Reteno SDK initialization;
• adding or updating FCM token handling;
• updating notification permission handling;
• adding Reteno push processing calls where required.

Ask the developer for manual help only if the step requires unavailable credentials, Firebase project access, Reteno dashboard access, or environment access that you do not have.

2. Request Firebase / FCM setup

Ask the developer to complete external Firebase or Reteno setup when it cannot be done from the codebase.

This may include:

• creating or confirming the Firebase project;
• providing the correct google-services.json;
• configuring Firebase Cloud Messaging;
• uploading Firebase service account / server configuration to Reteno;
• confirming that the selected Reteno mobile app is configured with token type FCM;
• confirming that the selected Reteno mobile app matches the selected test environment.

Continue only after the developer confirms that the external setup is complete.

3. Run the application

Ask the developer to run the application in the selected test environment.

The selected test environment can be:

• an Android emulator;
• a physical Android device;
• another supported test environment.

Use the environment confirmed by the developer for the current demo or validation run.

If push validation fails in the selected environment, ask the developer to confirm whether the issue is related to the test environment, Firebase setup, Reteno configuration, Android notification settings, or another integration problem.

4. Grant push notification permission

When the push notification permission prompt is displayed, ask the developer or user to allow notifications.

Continue only after permission is granted or the permission state is confirmed.

5. Interact with the test push notification

After the test push is sent and DELIVERED status is available, ask the developer to open the test push notification.

After the developer confirms that the push notification was opened, continue validation through Reteno MCP and verify CLICKED status.

6. Complete authentication, if required

If externalCustomerId validation is part of the current integration task, ask the developer or user to complete login or registration.

Continue only after authentication is completed.

7. Continue validation

After each manual step is completed:

• continue the SDK integration flow;
• continue validation through Reteno MCP;
• include all completed manual actions in the final report.

Validation Requirements

The agent must validate every Reteno SDK feature that it integrates, modifies, or is explicitly asked to verify.

Do not treat feature-specific validation as optional when the feature is part of the current integration task.

Core mobile push validation

When mobile push integration is included, the following checks are required:

• contact creation;
• mobilePushToken assignment;
• token type validation;
• test push sending;
• DELIVERED status;
• CLICKED status;
• final report.

Feature-specific validation

Run feature-specific validation for every Reteno SDK feature included in the current integration task.

Feature-specific validation may include:

• custom event validation;
• In-App message validation;
• mobile-push + In-App validation;
• externalCustomerId validation;
• deeplink validation;
• custom push data validation.

If a required feature-specific check cannot be completed, document the reason in the final report as one of the following:

• blocker;
• manual step;
• unsupported MCP action;
• missing MCP capability;
• unavailable test environment;
• unavailable Reteno UI / admin setup.

Local Device Automation / mobile-mcp Quick Check

Reteno MCP and local device automation are separate.

Reteno MCP is used for Reteno-side validation:

• contact lookup;
• mobilePushToken verification;
• token type validation;
• test push creation and sending;
• DELIVERED / CLICKED status checks.

Local device automation, such as mobile-mcp, is used for Android runtime interaction:

• launching the app;
• interacting with the Android emulator or physical device;
• granting notification permission;
• opening the delivered test push notification.

Local automation is not limited to mobile-mcp.

If mobile-mcp is unavailable, the agent may use another approved local automation method, such as:

• adb;
• uiautomator;
• Android Studio tools;
• manual developer / QA interaction.

This is not an Android SDK integration failure.

You must document which local automation method was used in the final report.
Before Android runtime validation, verify that local device automation is available in the current AI agent session.

For Claude Code, if mobile-mcp was added during the current or previous session, restart Claude Code before continuing.

Example setup command:

claude mcp add mobile-mcp -- npx -y @mobilenext/mobile-mcp@latest

After restart, ask the agent to verify that mobile-mcp tools are loaded.

If mobile-mcp is unavailable, do not treat this as an Android SDK integration failure.

Ask the developer or QA engineer to perform the required runtime actions manually:

• run the app;
• grant notification permission;
• open the delivered test push notification.

After the manual action is confirmed, continue Reteno MCP validation from the next required step.

Do not mark the integration as complete until runtime validation and Reteno MCP validation are completed, or the blocker is clearly documented.

Local Device Automation / mobile-mcp Quick Check

Reteno MCP and local device automation are separate.

Reteno MCP is used for Reteno-side validation:

• contact lookup;
• mobilePushToken verification;
• token type validation;
• test push creation and sending;
• DELIVERED / CLICKED status checks.

Local device automation, such as mobile-mcp, is used for Android runtime interaction:

• launching the app;
• interacting with the Android emulator or physical device;
• granting notification permission;
• opening the delivered test push notification.

Before Android runtime validation, verify that local device automation is available in the current AI agent session.

For Claude Code, if mobile-mcp was added during the current or previous session, restart Claude Code before continuing. The tool may not be available until the agent environment is restarted.

Example setup command:

claude mcp add mobile-mcp -- npx -y @mobilenext/mobile-mcp@latest

After restart, ask the agent to verify that mobile-mcp tools are loaded.

If mobile-mcp is unavailable, do not treat this as an Android SDK integration failure.

Ask the developer or QA engineer to perform the required runtime actions manually:

• run the app;
• grant notification permission;
• open the delivered test push notification.

After the manual action is confirmed, continue Reteno MCP validation from the next required step.

Do not mark the integration as complete until runtime validation and Reteno MCP validation are completed, or the blocker is clearly documented.

Validation With Reteno MCP

After applying Android SDK integration changes, validate the integration through Reteno MCP.

If the developer explicitly asks to skip validation, return a Partial report.

Do not mark the integration as Complete when build/run, runtime interaction, Reteno MCP validation, contact lookup, token verification, test push, DELIVERED, or CLICKED was skipped.

When validation is skipped, document:

• who requested the skip;
• which validation steps were not run;
• why they were not run;
• what is needed to resume validation;
• the exact step to resume from.

Available MCP capabilities

Use Reteno MCP only when the required MCP capability is available and authorized in the current environment.

Before starting MCP-based validation, verify that Reteno MCP is connected in the same environment where the AI coding agent runs.

For Android core mobile push validation, use Reteno MCP when the required capability is available and authorized in the current environment.

Core validation capabilities may include:

• finding a contact by contactId, if this MCP action is available;
• finding a contact by deviceId, if this MCP action is available;
• displaying the assigned mobilePushToken;
• identifying the token type: FCM;
• creating or selecting a test push notification;
• sending a test push notification;
• checking DELIVERED status;
• checking CLICKED status after the developer opens the push notification.

If a required MCP action is unavailable, document it as a missing MCP capability and continue with the remaining validation steps where possible.
For feature-specific In-App validation, Reteno MCP can be used when the required actions are available in the current environment.

In-App MCP actions may include:

• find In-App message by name;
• get In-App message details by ID or name;
• attach an existing In-App message to a mobile push;
• verify which In-App message is attached to a push;
• get In-App statuses for contact or message: Read, Click, Clicked.

Do not assume that an In-App message already exists in the selected Reteno account.

If the In-App message does not exist and MCP cannot create it, ask the developer or admin to create it manually in Reteno UI or wait until default In-App creation is available for the selected account.

[!NOTE]
Reteno MCP and local device automation tooling are separate.

Reteno MCP is used for Reteno-side validation:

• contact lookup;
• mobilePushToken verification;
• test push creation and sending;
• DELIVERED / CLICKED status checks.

Local device or emulator automation tooling is used for runtime interaction:

• running the app;
• granting notification permission;
• opening the test push notification.

If local device or emulator automation tooling is unavailable, ask the developer to perform the device interaction manually and continue after confirmation.

If Reteno MCP is unavailable, Reteno-side validation cannot be completed.

Validation flow

1. Check Android mobile app configuration

Verify that the selected Reteno mobile app is configured for Android push validation.

Expected configuration:

• platform: Android;
• token type: FCM;
• Firebase / FCM configuration is available in Reteno;
• the selected Reteno app matches the selected Android app package name / environment.

If Reteno MCP cannot read app-level push configuration, ask the developer or admin to confirm it manually.

Do not change app-level configuration automatically unless this action is explicitly supported and confirmed by the developer or admin.

2. Create or initialize an anonymous contact

Before login or registration, initialize the SDK and create an anonymous contact.

At this stage, the contact must be anonymous.

To verify that the contact was created, use Reteno MCP, backend data, logs, or Reteno UI.

Expected result:

• contactId is available;
• deviceId is available;
• platform / OS information is available;
• externalCustomerId is not required at this stage;
• mobilePushToken is not required at this stage.

Use contactId as the primary identifier. If Reteno MCP supports deviceId lookup, also verify that the same contact can be found by deviceId.

3. Validate contact attributes

Check whether the anonymous contact has valid timeZone and languageCode values.

1. Inspect the implementation:

   • find where the application creates or updates the anonymous contact;
   • check whether timeZone and languageCode are passed through SDK code;
   • if these values are generated automatically by the SDK, verify that the app does not override them with invalid custom values.

2. Verify the saved contact data in Reteno:

   • use Reteno MCP, Reteno UI, backend data, or logs to open the created anonymous contact;
   • confirm that the saved contact profile contains valid timeZone and languageCode values.

Expected format:

• timeZone must use TZ database format, for example Europe/Kyiv, Europe/Sofia, or America/New_York;
• languageCode must use RFC 5646 format, for example en, en-US, uk, uk-UA, or de-AT.

Do not use invalid values such as GMT+2, UTC+3, Kyiv, +02:00, english, EN, ua, or uk_UA.

4. Request push notification permission

Trigger or verify the Android push notification permission flow.

For Android 13 and later, notification permission may need to be requested at runtime.

Expected result:

• the app requests notification permission when required;
• notification permission is granted or the current permission state is confirmed;
• the SDK receives or can access the FCM token;
• the token is sent to Reteno;
• the token is assigned to the anonymous contact.

If the AI agent cannot interact with the selected test environment directly, ask the developer to complete the permission step manually and continue after confirmation.

5. Verify mobile push token assignment

After push permission is granted and the SDK is initialized, use Reteno MCP to verify the contact state.

Expected result:

• contactId is available;
• deviceId is available;
• mobilePushToken is available;
• osName is available;
• token type is FCM.

The token assigned to the Android contact must match the token type configured for the selected Reteno mobile app.

Expected Android token type:

• Android contact must have an FCM token.

6. Send a test mobile push

After the contact is created and mobilePushToken is assigned, use Reteno MCP to send a test mobile push to this contact.

Use a dedicated messageTag, for example test, to make push statuses easier to find.

7. Verify push delivery status

After sending the test push, use Reteno MCP or backend data to check push statuses.

Expected result:

• DELIVERED status is available for the test push.

If DELIVERED is not available and ERROR is present:

1. Check the error code.
2. Match the error code with Reteno mobile push error documentation.
3. Explain the likely reason.
4. Provide troubleshooting steps.

Possible causes may include:

• missing or invalid mobilePushToken;
• incorrect Firebase project or Sender ID;
• incorrect Reteno mobile app configuration;
• token type mismatch;
• invalid or outdated token;
• notification permission disabled;
• notification channel disabled;
• Firebase / FCM setup issue;
• SDK version or compatibility issue.

8. Verify push click tracking

After DELIVERED status is available, verify that push interaction is tracked.

The test push notification must be opened in the selected test environment.

The selected test environment can be:

• Android emulator;
• physical Android device;
• another supported environment confirmed by the developer.

If you can interact with the selected test environment directly and the required local automation permissions are granted, open the push notification yourself.

If you cannot interact with the selected test environment directly, ask the developer to open the push notification manually and continue after confirmation.

After the push notification is opened, use Reteno MCP to verify that the CLICKED status has been received.

Expected result:

• CLICKED status is available for the same test push.

9. Verify that push statuses belong to the same contact and message

For correct validation, all push statuses must belong to the same test push and the same contact.

Verify the following identifiers:

• contactId;
• deviceId;
• mobilePushToken;
• messageId;
• imid;
• iid;
• messageTag.

For Android core mobile push validation, verify:

• DELIVERED;
• CLICKED.

If ERROR is present, treat it as a troubleshooting path.

SENT may be available on the backend, but it is not the main success status for delivery validation.

10. Extended validation: Verify custom event delivery

Run this check only if custom event validation is included in the selected validation scope.

Before running this check, verify that Reteno MCP can retrieve events for the contact or that another verification method is available, such as Reteno UI, event log, backend logs, or API response.

If MCP cannot retrieve event list / count for the contact or verify that the event belongs to the expected contactId / deviceId, document the missing MCP action as a requested capability.

Create and send a test custom event through the SDK.

Use the following event name:

testAiEvent

Expected result:

• testAiEvent is received in Reteno;
• the event is assigned to the same contactId / deviceId used for mobile push validation;
• the event payload is available;
• the event can be found in backend logs, event log, or contact activity where applicable.

11. Optional: verify externalCustomerId after login or registration

Run this check only if the user explicitly wants to validate login or registration flow.

Before login or registration, the contact must remain anonymous.

Expected result before login or registration:

• contactId is available;
• deviceId is available;
• platform / OS information is available;
• externalCustomerId is not assigned yet.

After login or registration, the app / SDK must send a stable customer user ID to Reteno as externalCustomerId.

Expected result after login or registration:

• externalCustomerId is assigned;
• it is assigned to the same contact / device that was created anonymously before login or registration;
• mobilePushToken remains assigned to the correct contact;
• subsequent SDK events are sent to the contact with externalCustomerId.

Do not use unstable values as externalCustomerId, such as:

• deviceId;
• mobile push token;
• temporary session ID;
• random UUID generated on the device;
• email, if the product has a stable backend user ID.

12. Scope-based validation: Validate In-App message triggered by event

Run this check when In-App validation is included in the selected validation scope.

If In-App validation is part of the current task, this check is required and must not be skipped.

Use the same test contact that was used for anonymous contact creation, mobile push token validation, push status validation, and custom event validation.

To validate an In-App message triggered by an event:

1. Find the existing In-App message that should be used for validation.
2. Use the In-App message name or ID provided by the user, developer, or admin.
3. If the In-App message name or ID is not provided, ask the user, developer, or admin to provide it before continuing.
4. If MCP cannot find the In-App message by name or ID, ask the developer or admin to confirm that the In-App message exists in Reteno UI.
5. If the In-App message does not exist, ask the developer or admin to create it in Reteno UI.
6. Create or verify a test event named eventTestInApp, if this action is available.
7. Configure or confirm that the In-App message is triggered after eventTestInApp.
8. If MCP cannot configure the trigger, ask the developer or admin to complete this step manually in Reteno UI.
9. Publish or confirm that the In-App message is published and active.
10. Open the app in the selected test environment.
11. Send eventTestInApp to the same test contact, if this action is available.
12. Verify that the In-App message appears in the app.
13. If possible, click the button in the In-App message.
14. Verify In-App statuses for the same contact.

Expected result:

• the existing In-App message is found or confirmed by the developer/admin;
• the In-App message is published and active;
• the event, In-App message, and statuses belong to the same contact.

Do not require a hardcoded test event such as eventTestInApp.

If an approved existing In-App message already has a real trigger event, the agent may use that trigger only after developer or admin confirmation.

If MCP cannot create, configure, or wire an In-App trigger, use one of the following approved fallbacks:

• existing In-App message;
• existing trigger event;
• Reteno UI configuration;
• developer/admin manual confirmation.

Document the trigger event that was actually used.

13. Feature-specific validation: Mobile-push + In-App flow

Run this check when mobile-push + In-App validation is included in the selected validation scope.

If mobile-push + In-App validation is part of the current task, this check is required and must not be skipped.

Before attaching an In-App message to a mobile push, verify that the required Reteno MCP action is available in the current environment.

If the action is unavailable, ask the developer or admin to complete the step manually in Reteno UI and document the missing MCP capability.

If MCP cannot attach the In-App message to the push, ask the developer or admin to complete this step manually in Reteno UI and continue validation after confirmation.

To validate the mobile-push + In-App flow:

1. Find the existing In-App message that should be attached to the mobile push.
2. Use the In-App message name or ID provided by the user, developer, or admin.
3. If MCP cannot find the In-App message by name or ID, ask the developer or admin to confirm that it exists in Reteno UI.
4. Create a mobile push message through MCP, if this action is available.
5. Attach the existing In-App message to the mobile push message through MCP only if this action is supported.
6. If MCP cannot attach the In-App message to the push, ask the developer or admin to attach it manually in Reteno UI.
7. Send the mobile push message to the test contact.
8. Verify that push status DELIVERED is available.
9. Open the push notification in the selected test environment.
10. Verify that the app opens.
11. Verify that the In-App message appears.
12. Click the button in the In-App message, if possible.
13. Verify In-App statuses for the same contact.

Success Criteria

The Reteno Android SDK integration is successful only when you complete the required validation checks or clearly document a blocker.

Core Android mobile push validation success criteria

For the Android core mobile push validation flow, the integration is successful when:

• you detect the project as a native Android application;
• you add and configure the required Reteno Android SDK integration parts in the selected Android application;
• the app builds and runs successfully;
• push notification permission is granted or the permission state is confirmed in the selected test environment;
• an anonymous contact is created in Reteno;
• contactId is available;
• deviceId is available, if this data can be retrieved;
• mobilePushToken is assigned to the contact;
• the mobile push token type is FCM;
• the token type matches the selected Reteno mobile app configuration;
• you send a test push through Reteno MCP;
• push status DELIVERED is available;
• the developer opens the test push notification in the selected test environment;
• push status CLICKED is available after the push notification is opened;
• unresolved blockers are documented in the final report.

Feature-specific validation

The following checks are part of the extended validation flow and are not required for the Android core mobile push validation flow unless they are explicitly included in scope:

• custom event testAiEvent;
• In-App validation;
• mobile-push + In-App validation;
• externalCustomerId validation;
• deeplink validation;
• custom push data validation.

externalCustomerId identifier choice

When validating externalCustomerId, prefer a stable backend user ID.

If no stable backend user ID is exposed client-side and the agent uses another identifier, such as email, document this as a warning and product decision.

Do not use unstable identifiers such as:

• deviceId;
• mobile push token;
• temporary session ID;
• random UUID generated on the device.

If email is used because no stable backend ID is available, report this clearly in the final report.

Blocker handling

Do not report the integration as complete if:

• required validation was skipped;
• the app does not build;
• the app does not run;
• the selected test environment cannot be used;
• Reteno MCP cannot perform a required validation action;
• DELIVERED or CLICKED cannot be verified;
• the failure reason is unknown or undocumented.

Android Troubleshooting

Recurring Android SDK issue checks

When troubleshooting Android SDK integration, check recurring SDK issue patterns before escalating.

Common Android-related issues may include:

• DELIVERED or CLICKED statuses are missing;
• mobilePushToken is missing;
• pushSubscribed=false;
• Firebase / FCM token mismatch or missing token;
• incorrect Reteno mobile app configuration;
• SDK version compatibility issues;
• SDK initialization crashes;
• events are not tracked;
• deeplink handling does not work;
• In-App messages do not appear;
• ANR or WorkManager-related initialization issues.

Use these patterns as troubleshooting hints. Always verify the issue against the current project, official Reteno Android documentation, MCP results, logs, and build output before applying a fix.

mobilePushToken is missing

Check:

• notification permission status;
• FCM token generation;
• Firebase configuration;
• whether the FCM token was passed to Reteno;
• whether Reteno app is configured with FCM token type;
• pushSubscribed state;
• SDK version.

SDK initialization crashes

Check:

• SDK version;
• initialization location;
• custom Application class;
• AndroidManifest registration;
• debug logs;
• database / migration errors;
• WorkManager initialization issues.

In-App MCP status capability is unavailable or returns an error

If the MCP capability for In-App statuses is unavailable or returns an error, do not fail the entire integration immediately.

Use approved fallback evidence when available:

• Reteno UI;
• backend data;
• SDK logs;
• device logs;
• on-device screenshot or screen recording;
• developer / QA confirmation.

Document:

• which MCP capability failed;
• the MCP error, if available;
• which fallback evidence was used;
• whether the In-App message appeared;
• whether display / read / click evidence was available;
• whether the result is completed, manual fallback required, missing MCP capability, or blocked.

ANR/WorkManager issues

Check:

• Android debug mode logs;
• WorkManager initialization;
• custom WorkerFactory setup;
• SDK version;
• whether the issue reproduces on the selected emulator/device.

Contact is not found

If Reteno MCP cannot find the contact, check:

• SDK initialization;
• SDK access key;
• custom Application class;
• AndroidManifest.xml registration;
• app launch;
• network connection;
• whether the app was run after SDK integration changes;
• whether Reteno MCP has access to the correct Reteno app or environment.

Expected result:

• the contact is found by contactId;
• the contact has the expected Android platform / OS information.

If the contact still cannot be found, document this as a blocker.

pushSubscribed=false

If pushSubscribed=false or the contact cannot receive pushes, check:

• Android notification permission;
• notification channel state;
• whether notifications are disabled in Android OS settings;
• whether the app received an FCM token;
• whether the FCM token was passed to Reteno;
• whether the selected Reteno app uses the correct FCM configuration;
• whether the device should be resubscribed after notifications are re-enabled.

Expected result:

• notification permission is granted;
• notification channel is enabled;
• mobilePushToken is available;
• contact can receive push notifications.

Token type or Firebase configuration mismatch

If the token type or push provider configuration does not match the selected Reteno app, check:

• selected Reteno mobile app;
• Firebase project;
• google-services.json;
• FCM Sender ID;
• package name / applicationId;
• Reteno app FCM configuration;
• whether the token assigned to the contact is the expected FCM token.

Expected result:

• Android contact has an FCM token;
• token belongs to the correct Firebase project;
• selected Reteno mobile app is configured for Android / FCM.

DELIVERED status is missing

If the test push is sent but DELIVERED status is missing, check:

• mobilePushToken;
• Firebase / FCM configuration;
• Reteno mobile app configuration;
• notification permission;
• notification channel state;
• selected test environment;
• SDK version;
• push error codes.

If ERROR is present, follow these steps:

1. Check the error code.
2. Match the error code with Reteno mobile push error documentation.
3. Explain the likely reason.
4. Provide the next troubleshooting step.

CLICKED status is missing

If DELIVERED status is available but CLICKED status is missing, check:

• whether the developer opened the test push notification;
• whether the app opened after the push notification was tapped;
• push click listener / handler setup;
• Reteno push processing calls;
• deeplink or launcher activity behavior;
• whether the push belongs to the same contact and message.

After the developer confirms that the push notification was opened, use Reteno MCP to check CLICKED again.

Local device MCP / automation tool is added but not available

If a local device automation MCP server was added during the current agent session but is not available yet, ask the developer to restart the agent environment and verify that the tool is loaded.

For Claude Code, after adding a local MCP server, restart Claude Code before continuing with device or emulator automation.

Do not continue runtime validation until the required device automation tool is available or the developer confirms that manual device interaction will be used.

SDK access key is missing or placeholder

If the SDK access key is missing or still uses a placeholder value, do not continue runtime validation.

A placeholder key may allow the project to build, but it blocks real SDK registration and Reteno validation.

Ask the developer to provide the real SDK access key through the approved project configuration method.

Document the key handling method in the final report. Do not include the key value in the final report.

Deeplink handling does not work

If deeplink handling does not work after push click, check:

• intent filters in AndroidManifest.xml;
• launcher activity;
• onCreate / onNewIntent handling;
• custom data payload;
• whether the push contains a link the app can handle;
• whether the link falls back to the system browser;
• existing deeplink handling logic that must be preserved.

Do not overwrite existing deeplink handling. Add Reteno-related processing only where required.

Events are not tracked

If events are not tracked, check:

• SDK initialization;
• contact assignment;
• network connection;
• SDK version;
• event name;
• event payload;
• whether the event is sent before SDK initialization is complete;
• whether Reteno MCP, Reteno UI, logs, or event log can verify the event.

If MCP cannot retrieve event list / count for the contact, document this as a missing MCP capability.

Build or run fails

If the app does not build or run, check:

• dependency setup;
• SDK version;
• Gradle configuration;
• app module configuration;
• Firebase plugin configuration;
• package name / applicationId;
• google-services.json;
• manifest configuration;
• selected test environment configuration;
• runtime crash logs, if available.

Try to resolve the issue only when it can be fixed safely through code, dependency setup, project configuration, or supported tooling.

Do not retry the same fix indefinitely.

After two unsuccessful attempts to fix the same build, launch, emulator, or runtime crash issue, ask the developer to run the app through Android Studio or Gradle and provide:

• exact error message;
• crash reason, if available;
• relevant logs;
• emulator or device details;
• reproduction steps.

Do not continue MCP validation until the app builds and runs, or the build/run blocker is clearly documented.

SDK access key is missing or placeholder

If the SDK access key is missing or still a placeholder, do not continue runtime validation.

The app may build with a placeholder key, but real SDK registration, contact creation, token assignment, and push validation cannot pass.

Ask the developer to provide the real SDK access key through the approved project configuration method.

Do not print the key in logs, screenshots, public files, committed files, or the final report.

mobile-mcp is unavailable

If mobile-mcp or another local device automation tool is unavailable, do not treat this as an Android SDK integration failure.

Ask the developer or QA engineer to complete runtime actions manually:

• run the app;
• grant notification permission;
• open the delivered test push notification.

Continue Reteno MCP validation after manual confirmation.

If mobile-mcp was added during the current Claude Code session, restart Claude Code before retrying.

Build/run is blocked by an unrelated app issue

If the app cannot build, install, or launch because of an issue unrelated to Reteno SDK integration, identify the root cause before changing Reteno-related code.

Apply only the smallest safe fix required to unblock runtime validation.

Document:

• failed command or runtime action;
• observed error;
• why the issue is unrelated to Reteno;
• files changed;
• whether developer confirmation was required;
• whether the fix changes app behavior, package identity, SDK requirements, product compatibility, signing, Firebase configuration, or Reteno dashboard configuration.

minSdkVersion change is required

If the selected Reteno SDK version requires a higher minSdkVersion, do not apply the change automatically.

Ask the developer for explicit approval.

Document:

• previous minSdkVersion;
• required minSdkVersion;
• whether the developer approved the change;
• which Android versions are no longer supported;
• whether any lint or compatibility issues were introduced.

Final Report Format

At the end of the integration, return a structured final report.

Do not report only that the integration is complete. Include what you inspected, what you changed, what you validated, and what still requires attention.

Required report fields

Use the table below as the final report template.

Fill in the Result column after completing the integration and validation flow. If a field cannot be verified, explain why and mark it as a blocker or not available.

Use not requested for this integration for feature-specific checks that were not part of the current integration task.

Do not use MVP, extended validation, optional, or out of scope wording for feature-specific checks.

Do not include full SDK access keys, Firebase server credentials, private keys, certificates, service account data, or full push tokens in the final report.

Android core mobile push validation report

For Android core mobile push validation, include:

• whether the project was detected as a native Android application;
• evidence used for Android detection;
• which Android app module was used;
• package name / applicationId;
• dependency manager / build system;
• current minSdkVersion;
• whether minSdkVersion was changed;
• whether the minSdkVersion change was explicitly approved by the developer;
• whether Reteno SDK dependency was added or updated;
• whether Firebase Messaging dependency was added or confirmed;
• whether google-services.json was found and matched the selected app;
• whether existing Firebase / FCM setup was preserved;
• whether existing FirebaseMessagingService or notification handlers were preserved;
• whether SDK initialization was configured;
• whether push notification permission handling was configured or confirmed;
• whether FCM token handling was configured or confirmed;
• which files were inspected;
• which files were changed;
• whether unrelated build/run blockers were found and fixed;
• whether the app built and ran successfully;
• which test environment was used;
• whether local device automation / mobile-mcp was available;
• whether manual runtime actions were requested or completed;
• whether Reteno MCP was connected;
• whether Reteno MCP found the contact;
• whether mobilePushToken was assigned to the contact;
• whether token type was FCM;
• whether the token type matched the selected Reteno mobile app configuration;
• whether the test push was sent;
• whether DELIVERED status was received;
• whether the developer or agent opened the test push notification;
• whether CLICKED status was received after the push notification was opened;
• whether any blocker prevented validation.

Feature-specific validation report

Use this section for Reteno SDK features that are not part of the core Android mobile push validation flow.

Feature-specific validation may include:

• custom event validation;
• In-App message validation;
• mobile-push + In-App validation;
• externalCustomerId validation;
• deeplink validation;
• custom push data validation;
• action button validation.

For each feature-specific check, report one of the following statuses:

• completed;
• not requested for this integration;
• blocked;
• manual fallback required;
• missing MCP capability;
• unavailable test environment;
• unavailable Reteno UI / admin setup.

If a feature was not part of the current integration task, report it as:

not requested for this integration

If a feature was part of the current integration task but could not be validated, do not mark it as not requested.

Mark it as blocked, manual fallback required, missing MCP capability, or another relevant blocker status, and explain why.

Use this wording:

• custom event validation: completed / blocked / not requested for this integration;
• In-App validation: completed / blocked / manual fallback required / missing MCP capability / not requested for this integration;
• mobile-push + In-App validation: completed / blocked / manual fallback required / missing MCP capability / not requested for this integration;
• externalCustomerId: completed / blocked / not requested for this integration;
• deeplink validation: completed / blocked / not requested for this integration;
• custom push data validation: completed / blocked / not requested for this integration.

If a feature-specific check was completed, include:

• which contact or test audience was used, using redacted identifiers if needed;
• which event, push, deeplink, or In-App message was used;
• whether the result was verified through Reteno MCP, Reteno UI, backend data, logs, or manual confirmation;
• whether any manual fallback was required;
• any blocker or follow-up action.

Do not use the following wording:

• MVP;
• extended validation;
• out of MVP scope;
• optional;
• included in scope;
• selected validation scope.

Use instead:

• core Android mobile push validation;
• feature-specific validation;
• part of the current integration task;
• not requested for this integration.

Failed validation

If any validation step fails, include:

• failed step;
• observed result;
• expected result;
• likely cause, if known;
• whether the failure is related to Reteno SDK integration or an unrelated build/run issue;
• whether the app built and ran successfully;
• whether the selected Android test environment was available;
• whether local device automation / mobile-mcp was available;
• whether manual runtime action was requested or completed;
• whether Reteno MCP was connected;
• whether the required MCP capability was available;
• relevant contact, device, token, or push identifiers only when needed for troubleshooting, using redacted values;
• push message identifier, if available;
• MCP response or error details, if available;
• logs or screenshots requested from the developer, if applicable;
• recommended next step;
• exact step from which validation should resume.

Do not include full SDK access keys, Firebase server credentials, service account data, private keys, certificates, or full push tokens in the final report.

Blocker reporting

If a blocker prevents the integration or validation from being completed, report:

• what is blocked;
• why it is blocked;
• who needs to resolve it;
• whether the blocker is related to:
  • SDK access key;
  • Firebase / FCM setup;
  • Reteno app configuration;
  • build/run;
  • Android emulator or physical device;
  • local device automation / mobile-mcp;
  • Reteno MCP;
  • missing MCP capability;
  • manual runtime action;
  • unrelated application issue;
  • minSdkVersion / compatibility decision;
• whether the remaining non-blocked steps can continue;
• what should be done next;
• exact step from which validation should resume.

The report type must be Partial if any required build, run, runtime interaction, Reteno MCP validation, contact lookup, token verification, test push, DELIVERED, or CLICKED check was skipped, blocked, or not verified.

Do not mark the integration as complete if a required validation step failed, was skipped, or could not be verified.