Guides
  1. Developer Guides
  2. SDKs

Attentive Android SDK

Who this guide is for

This guide is for product managers, app developers, and other stakeholders responsible for planning, scoping, or overseeing an Attentive mobile SDK integration on Android.

For a fuller walkthrough of how the Attentive mobile SDK works, such as identity, events, creatives, and verification, start with the more detailed Attentive iOS SDK guide. This guide follows the same onboarding sequence but focuses on the decisions and verification steps that are specific to Android.

It explains what the SDK enables, the decisions teams need to make, the implementation sequence, and how to confirm that each phase works. It is not a step-by-step coding reference. Engineers should use the Android SDK README for dependency declarations, API signatures, and maintained code samples.

What the Android SDK does

The Attentive Android SDK connects user behavior in your app to Attentive. It can:

  • Collect email and SMS subscribers through in-app sign-up experiences.
  • Identify users and associate their activity across sessions.
  • Record commerce and custom events for journeys, personalization, and attribution.
  • Register devices for push notifications when Attentive is the push provider.
  • Handle notification opens and deep links so users land on the intended screen.

Your engineering team adds the SDK to the app, initializes it at launch, and instruments the relevant authentication, event, message, and creative flows. Those signals then become available in Attentive for activation and reporting.

If your app is built by a mobile app vendor or on a platform that limits third-party SDKs, confirm the supported integration path with your vendor and Attentive contact before scoping the work.

What is different on Android

Core identity, event, creative, and attribution behavior is largely the same as on iOS. The main Android-specific difference is push transport:

  • Push transport: Android uses Firebase Cloud Messaging (FCM), including Android-specific permission, service, and notification-icon decisions.

Decisions to make before implementation

  • Device support: Review the app's minimum supported Android version. Do not raise it solely for the SDK without an explicit product decision.
  • Account configuration: Obtain the Attentive domain used to initialize the SDK and decide which environments will use production or debug behavior.
  • Push ownership: Decide whether Attentive will be the app's push provider. If yes, confirm the app already has or will add a working Firebase setup.
  • Existing push service: Ask whether the app has its own FirebaseMessagingService. If it does, engineering may need to forward Attentive messages to the SDK.
  • Permission ownership: Choose whether Attentive or the host app controls the Android 13+ notification-permission prompt.
  • Notification design: Provide a small monochrome notification icon that follows Android's status-bar requirements.
  • Identity and event plan: Agree on login/logout behavior, identifiers, commerce events, custom events, and deep-link destinations before implementation.
  • App architecture: Flag web-based browse, cart, or checkout flows early so native and web tracking can be coordinated.
  • Launch ownership: Name the engineering owner, product owner, Attentive contact, and the evidence required for sign-off.

How the integration is sequenced

Complete the phases in this order. Each phase depends on the one before it and ends with a practical verification step.

1. Install the SDK

Select the latest stable Attentive Android SDK version on Maven Central.

Verify: the dependency resolves and the app still builds. Test on a device or emulator running API 26 or above.

2. Initialize at app launch

Initialize the SDK in the onCreate() of your Application subclass. If Attentive is not the push provider, disable push during initialization; identity, event tracking, and creatives still work.

Verify: launch the app and confirm Attentive initialization appears in logcat shortly after startup.

3. Wire identity

Most integrations identify users with email. Phone is also supported. If the app needs a durable identifier beyond email or SMS, clientUserId is the recommended choice.

The standard lifecycle is to identify the shopper at login and clear the user at logout. Clearing the user prevents later activity or targeted push from remaining associated with the person who signed out. Use updateUser only to switch directly from one signed-in person to another without an anonymous state in between.

Never hard-code a shared test email or phone number. That can collapse multiple testers into one subscriber profile and make results unreliable.

Verify: the expected subscriber appears in Attentive with the identifiers the app sent. Test login, logout, account switching, and a fresh install.

4. Record events

Record standard commerce events at the same business-logic points that feed the app's analytics or order systems: product view, add to cart, and purchase. Use a custom event only when an action falls outside those cases, and agree on its name and properties before production data begins flowing.

Include a stable deep link when a journey should return the user to a product, cart, or another specific screen. The app, not the SDK, owns the destination and final navigation behavior. If checkout runs inside an Android WebView, bridge completed-purchase data back to the native app and record the purchase through the SDK. If that is not possible, include a stable identifier—such as email, phone, or clientUserId—in the web checkout so the purchase can be associated with the same Attentive profile. Coordinate the web and native implementations so the purchase is sent once.

Verify: ask your Attentive contact to confirm that test events and payloads arrive under the correct company domain. An on-device success alone does not prove the event reached the intended account.

5. Set up push, if applicable

Skip this phase when Attentive is not the push provider. Otherwise, Android push requires a working FCM setup and four explicit checks:

  • Firebase readiness: The app is registered with Firebase and includes the required Firebase configuration and messaging dependency.
  • Message routing: If the app already has a Firebase messaging service, Attentive messages are forwarded to the SDK. Without forwarding, notifications can be silently dropped.
  • Permission flow: On Android 13 and above, the user must grant notification permission. Decide whether the SDK or the app owns the prompt and ensure Attentive receives the result.
  • Notification presentation: Use a compliant monochrome status-bar icon; a full-color asset can render as a solid square.

Verify: configure Android push credentials in Attentive, then work with your Attentive contact to send a test notification. Confirm that the expected profile has an FCM token; the notification appears in foreground, background, and terminated states; the icon renders correctly; and tapping it opens the intended screen. Test the permission flow on Android 13+ and at least one earlier version.

6. Show sign-up creatives

Trigger the in-app sign-up experience from an intentional screen and attach it to the appropriate view and activity lifecycle. The SDK uses a webview only to render Attentive sign-up creatives; it does not render product, cart, checkout, or other app screens. In debug or staging builds, teams may bypass creative fatigue rules for repeatable testing; production should use normal eligibility behavior.

A creative may be ineligible or may fail to open. Treat those outcomes as expected states and keep the rest of the app usable.

Verify: an eligible test creative opens on a fresh test state, its callback reports the outcome, and non-opening outcomes do not block the app UI.

Sample launch sign-off checklist

Copy this checklist into the launch ticket and add an owner, evidence link or screenshot, status, and approval date to each line.

  • The SDK resolves through the app's existing Gradle configuration and the app builds on API 26+.
  • Initialization happens in the onCreate() of the app's Application subclass and uses the correct Attentive domain and environment.
  • Identity behavior is tested across login, logout, account switching, and reinstall scenarios.
  • Commerce events match the app's source-of-truth analytics or order paths.
  • Custom event names and payloads are agreed before production data begins flowing.
  • If Attentive provides push, Firebase configuration, service forwarding, permission ownership, notification icons, and notification taps are verified.
  • Creative eligibility, failure handling, lifecycle cleanup, and deep-link routing are tested on real devices.
  • Privacy disclosures, permissions, and Google Play requirements are reviewed by the appropriate internal owners.
  • SDK upgrades follow the team's normal release process: review the changelog, test in staging, and validate on a real device.

Appendix A: Event planning

The Android SDK supports purchase, add-to-cart, product-view, and custom events. Product events require stable product and variant identifiers plus price and currency. Purchases also need a unique order identifier. Optional fields can add product names, images, quantities, categories, carts, and deep links.

Use custom events for meaningful actions that are not standard commerce events, such as loyalty enrollment, appointment booking, store-locator use, quiz completion, or content viewed. Event names and property keys are case-sensitive, so agree on the schema before launch and keep it stable.

Appendix B: Deep links on Android

A deep link should be a stable URL that maps to one specific destination, such as a product detail page or cart. The SDK passes the URL to the app; the app remains responsible for intent filters, App Links verification, navigation, and any required authentication.

Review your activity's launch mode. Apps using singleTask need to override onNewIntent() so the SDK can detect notification opens when the app is already running. Engineering should consume each deep link once to avoid duplicate navigation.

  • The URL opens the intended screen on a fresh install.
  • The route works when the app is foregrounded, backgrounded, and terminated.
  • Logged-out users follow the intended authentication path before navigation.
  • The link is consumed only once.
  • Product and cart URLs use stable identifiers rather than temporary session state.

Optional: agent-assisted setup

The Android SDK includes an AGENTS.md integration guide that can help an AI coding agent add the dependency, initialize the SDK, and guide the push setup. This workflow is experimental and every change should be reviewed before commit.

The agent flow intentionally does not decide where to wire identity, commerce events, or creatives. Those choices belong to the app team because they depend on authentication, checkout, and product-screen behavior.

Helpful links

Updated 1 day ago

Did this page help you?