Common Live activities troubleshooting scenarios troubleshoot-mobile-live

You can use Assurance to verify token registration:

1. In Assurance, from the Events list, filter or search for events eventType = "liveActivity.pushToStart".
2. Select the Event and inspect the payload.
3. Check that the token, appId, and attributeType values are present.
4. Confirm that the event was sent successfully.

You can also check in Adobe Experience Platform profile.

1. In Adobe Experience Platform, from your Profile, access the Events tab.
2. Search for liveActivity.pushToStart events.
3. Check the event timestamp and payload.

If no events are found, the app is not calling Messaging.registerLiveActivities correctly. Fix the SDK integration.

1. From your Profile, access the Attributes tab.

2. Locate liveActivityPushNotificationDetails.

3. Verify the token configuration:

   code language-json
   { "liveActivityPushNotificationDetails": [ { "appId": "com.example.myapp", "token": "abc123def456...", "platform": "apns", "denylisted": false, "attributeType": "OrderTrackingAttributes", "identity": {} } ] }

Validate each field:

If any field is incorrect, update the mobile app, re-register using Messaging.registerLiveActivities, wait 5-10 minutes, then re-check.

If liveActivityPushNotificationDetails is missing, the token has not synced yet. Wait 5-10 minutes after you see the liveActivity.pushToStart event in Assurance, then re-check.

Android uses the standard FCM registration token for Live activities. There is no liveActivity.pushToStart event or separate Live activity push token.

1. In Assurance, open the Events list and locate the standard push-token registration event.
2. Select the event and inspect its payload to verify that the FCM registration token is present.
3. Confirm that the registration event was successfully sent.
4. In Adobe Experience Platform, open your profile’s Attributes tab and confirm that the token is present in pushNotificationDetails, as described in step 2.

If the registration event or profile token is missing, verify that the app forwards the FCM registration token to the SDK using MobileCore.setPushIdentifier(token).

1. From your profile, access the Attributes tab.

2. Locate pushNotificationDetails. Android uses this object instead of liveActivityPushNotificationDetails and does not require an attributeType field.

3. Verify that the token configuration follows this structure:

   code language-json
   { "pushNotificationDetails": [ { "appId": "com.adobe.marketing.mobile.liveupdatessample", "token": "fcm-registration-token...", "platform": "fcm", "denylisted": false, "identity": {} } ] }

Validate each field:

If any field is incorrect, correct the app configuration as needed, forward the FCM token again using MobileCore.setPushIdentifier(token), wait 5-10 minutes, then re-check the profile.

If pushNotificationDetails is missing, the token has not synced yet. After confirming token registration in Assurance, wait 5-10 minutes, then re-check the profile.

1. In Journey Optimizer, open your Campaign and navigate to the Actions menu.
2. Check your Live activity configuration. The surface must be configured for the iOS app with a bundle identifier that matches the appId in your profile’s liveActivityPushNotificationDetails. For example, if your profile has "appId": "com.example.myapp", the surface must target that same app.
3. Check that the Activity type in your campaign configuration matches exactly the attributeType in your profile’s liveActivityPushNotificationDetails. For example, if your profile has "attributeType": "FoodDeliveryLiveActivityAttributes", the campaign must specify this same Activity type.

When executing the campaign via API, ensure the payload follows the correct structure.

Unitary payload:

{
   "campaignId": "your-campaign-id",
   "recipients": [{
      "type": "aep",
      "userId": "user@example.com",
      "namespace": "email",
      "context": {
         "requestPayload": {
            "aps": {
               "content-available": 1,
               "timestamp": 1756984054,
               "event": "start",
               "attributes-type": "FoodDeliveryLiveActivityAttributes",
               "content-state": { ... },
               "attributes": { ... }
            }
         }
      }
   }]
}

Common payload issues:

Critical: Always use a fresh timestamp

• Set timestamp to the current Unix epoch time (in seconds) at the moment you make each API call. This applies to all event types: start, update, and end.
• A stale or reused timestamp causes update and end requests to fail or be ignored by the device. Do not reuse timestamps from previous requests or cached values.

Optional fields (all event types):

• requestId: Unique identifier for tracking (recommended).
• alert: Object with title and body for the notification. Useful for drawing attention to updates.

About dismissal-date:

• Optional. Unix epoch time in seconds. Relevant only when event is "end".
• Specifies when the Live activity is automatically removed from the device. If you omit it, the Live activity remains visible until the user dismisses it.
• Must be a future timestamp, later than timestamp.

Ensure your API payload matches your iOS app’s ActivityAttributes implementation. The Adobe SDK’s LiveActivityAttributes protocol extends iOS ActivityAttributes and requires a liveActivityData property.

Validate the mapping:

1. Your ActivityAttributes must implement Adobe’s LiveActivityAttributes protocol. Example:

   code language-swift
   struct FoodDeliveryLiveActivityAttributes: LiveActivityAttributes { public struct ContentState: Codable, Hashable { var orderStatus: String var estimatedDeliveryTime: String } // Adobe SDK requirement var liveActivityData: LiveActivityData // Your custom attributes var restaurantName: String }

   Note that the liveActivityData field is required by Adobe SDK and must be included in all implementations.

2. Your API payload must mirror the iOS structure:

   code language-json
   { "aps": { "event": "start", "timestamp": 1756984054, "attributes-type": "FoodDeliveryLiveActivityAttributes", "content-state": { "orderStatus": "Preparing", "estimatedDeliveryTime": "20 mins" }, "attributes": { "liveActivityData": { "liveActivityID": "order-12345" }, "restaurantName": "Pizza Palace" } } }

Validation checklist:

• Include all ContentState fields in content-state (required for all event types).

• Include all LiveActivityAttributes fields in attributes (start events only), including:

  • liveActivityData (required; typically contains liveActivityID or similar identifier)
  • All custom fields from your struct

• Match field names exactly (case-sensitive).

• Match data types (String, Int, Bool, nested objects).

• Preserve nested object structure.

Common mistakes:

For more examples, refer to Create Live activity page.

Verify API execution and payload delivery using Assurance:

1. Open your Assurance session.

2. Execute the API call to trigger the Live activity.

3. In the Event List, check for:

   • Campaign execution events.
   • Live activity delivery events.
   • Payload validation error events.

4. Review event payloads to verify:

   • Payload was processed correctly.
   • No validation errors occurred.
   • Live activity was sent to APNs.

1. In Journey Optimizer, open your Campaign and navigate to the Actions menu.
2. Check your Live activity configuration. The surface must target the Android app with a package name that matches the appId in the profile’s pushNotificationDetails.
3. Verify that the surface uses the FCM credentials for that app. The profile’s token platform must be "fcm".
4. Confirm that notification_channel_id in the payload matches a notification channel created by the app.

Place Android Live activity fields under context.requestPayload.fcm.

Unitary start payload:

{
   "requestId": "your-request-id",
   "campaignId": "your-campaign-id",
   "recipients": [
      {
         "type": "aep",
         "userId": "your-device-ECID",
         "namespace": "ECID",
         "context": {
            "requestPayload": {
               "fcm": {
                  "notification_id": "flight-DL-321",
                  "timestamp": 1756984054,
                  "notification_channel_id": "live_updates_channel",
                  "priority": "PRIORITY_HIGH",
                  "event_type": "start",
                  "title": "Flight DL-321",
                  "body": "Boarding starts shortly",
                  "critical_text": "25 min",
                  "content_state": {
                     "custom_key_template_type": "progress",
                     "custom_key_journey_start": "DEL",
                     "custom_key_journey_progress": 10,
                     "custom_key_journey_end": "MUM"
                  }
               }
            }
         }
      }
   ]
}

Replace the sample timestamp with the current Unix epoch time in seconds. The content_state keys are examples and must match your app’s style provider.

For broadcasts, use an API-triggered Marketing campaign with audience.id and place the fcm object under context.requestPayload. Set topic_name to the FCM topic subscribed to by the target devices. Keep the topic and notification_id unchanged across start, update, and end events. See the Android broadcast payload examples.

Common payload issues:

Timestamp and lifecycle checks:

• Use a fresh timestamp in epoch seconds for every start, update, and end event. Ensure that it is greater than the previous value for the same notification_id (or topic_name for broadcasts), even when requests are made within the same second.
• Older or equal timestamps are ignored. Do not reuse cached timestamps.
• The optional when field controls the notification’s displayed time, not message ordering. Keep it reasonably current and express it in epoch seconds.
• To update or end an activity, change event_type while keeping notification_id unchanged. Android uses the same FCM registration token for all three lifecycle events; no separate update token is required.

End-event dismissal:

For event_type: "end", optionally set dismiss_after to the number of seconds the completed Live activity should remain visible before removal. This is a duration, not an epoch timestamp.

The app’s style provider determines how content_state values render in the Live activity notification.

1. Confirm that Messaging and the Live Activities extension are integrated in the app.
2. Verify that each field in content_state matches a key handled by the style provider, including its expected value type.
3. Check that title, body, and critical_text contain the intended display text. critical_text is used for the status-bar chip.
4. Confirm that notification permissions are granted and that the channel identified by notification_channel_id exists.

Common mistakes:

For more examples, refer to Create Live activities.

Use Assurance on a connected Android test device.

1. Open an Assurance session and confirm that the FCM token registration is visible.
2. Execute the API call to start the Live activity, then send update and end events with the same notification_id and increasing timestamps.
3. Review the available SDK events and payloads for processing or validation errors. Confirm that the Android payload uses fcm and the intended lifecycle values.
4. In the profile’s Events tab, inspect matching message.feedback events. Check that serviceProvider is fcm, and review feedbackStatus, errorCode, and errorMessage for delivery failures.
5. If delivery succeeds but the Live activity does not render, inspect app logs, style-provider mappings, notification permissions, and channel configuration on the device.

Skip this step if the campaign report shows no send errors. Otherwise, match the error from the Error Reasons table to the following common APNs errors:

1. Navigate to Customer > Profiles in Journey Optimizer.

2. Search for and open the profile.

3. Select the Events tab.

4. Filter or search for events with eventType = "message.feedback".

5. Look for feedback events matching your Live activity’s liveActivityID and event type.

6. Review the following key fields:

   table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3
   Field	Possible Values	What it means
   feedbackStatus	sent, error, denylist	Delivery outcome from service provider
   serviceProvider	apns/apnsSandbox	Should be APNs for iOS Live activities
   errorCode	Numeric code or null	APNs-specific error code if failed
   errorMessage	Error description or null	Human-readable error message

7. If feedbackStatus: "error":

   • Check the errorCode and errorMessage for specific APNs errors.
   • Common APNs errors include expired token, invalid certificate, wrong bundle ID.

8. If no feedback event is found:

   • The push notification may not have been attempted.
   • Check whether the profile was excluded in the campaign report.

If feedbackStatus is sent: Journey Optimizer handed the notification to APNs. This does not confirm device rendering. Continue with the device-side checks in step 4.

1. Open your Assurance session and keep it active during the API call.

2. Execute the API call (start, update, or end).

3. In the Event List, look for Live activity delivery events.

4. Search for events related to APNs push delivery.

5. Check for the following indicators:

   • Push request to APNs: Confirms Adobe sent the push to Apple’s servers
   • APNs response: Shows whether APNs accepted or rejected the push
   • Delivery status: Success or failure indication

6. If issues are found, refer to the following common APNs delivery issues:

   table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3 5-row-3
   Issue	Symptom in Assurance	Resolution
   APNs certificate expired	Authentication error	Renew and upload new APNs certificate
   Wrong environment (dev vs prod)	Token mismatch error	Ensure certificate matches app build type
   Bundle ID mismatch	Invalid bundle identifier	Verify certificate bundle ID matches app
   Token expired	InvalidToken error from APNs	Re-register Live activity tokens
   Rate limiting	Too many requests	Reduce API call frequency

If Adobe shows successful delivery but the device does not show the Live activity:

• Check iOS device logs for Live activity errors.
• Verify that the app is in the foreground or background (not terminated).
• Confirm that the device has network connectivity.
• Test on multiple devices to rule out device-specific issues.
• Verify iOS version is 16.1 or later.

If you have completed all steps and the issue remains unresolved, contact Adobe Customer Care with:

Required information:

• Campaign ID and name
• Profile namespace and ID
• liveActivityID from API payload
• Timestamps of API calls
• Campaign report screenshots showing Sending Statistics, Error Reasons, and Excluded Reasons
• Relevant profile events (liveActivity.updateToken for unitary update/end issues and message.feedback)
• Assurance session details and relevant event screenshots
• API request payload and response, with credentials and device tokens redacted
• APNs certificate details (expiration, environment, bundle ID)

Skip this step if the campaign report shows no send errors. Otherwise, match the error from the Error Reasons table to the following common FCM errors:

1. Navigate to Customer > Profiles in Journey Optimizer.

2. Search for and open the profile.

3. Select the Events tab.

4. Filter or search for events with eventType = "message.feedback".

5. Locate feedback events for the campaign and API call timestamps you are investigating.

6. Review the following key fields:

   table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3
   Field	Possible Values	What it means
   feedbackStatus	sent, error, denylist	Delivery outcome from service provider
   serviceProvider	fcm	FCM handled Android push delivery
   errorCode	Provider error code or null	FCM-specific error code if delivery failed
   errorMessage	Error description or null	Human-readable error message

7. If feedbackStatus: "error":

   • Inspect errorCode and errorMessage and apply the corresponding FCM resolution from step 1.

8. If no feedback event is found:

   • The push notification may not have been attempted or feedback may not yet be available.
   • Check whether the profile was excluded in the campaign report.

If feedbackStatus is sent: FCM accepted the notification. This does not confirm that the device rendered the Live activity. Continue with the device-side checks in step 4.

Use Assurance on a connected Android test device.

1. Open an Assurance session and keep it active during the API call.
2. Execute the API call with event_type set to start, update, or end.
3. In the Events list, inspect available push-delivery events for the request to FCM and its response.
4. Check whether FCM accepted or rejected the request, and inspect any reported error details.
5. For rejected requests, use the FCM errors in step 1 to check the token, Firebase project credentials, and payload. If provider events are unavailable in the session, use message.feedback events and campaign reports.

If Adobe shows successful delivery but the device does not display or update the Live activity:

• Inspect Android app logs for push-handling and Live activity rendering errors.
• Confirm that notifications are allowed and that promoted notifications are permitted using canPostPromotedNotifications().
• Verify that POST_NOTIFICATIONS and POST_PROMOTED_NOTIFICATIONS permissions are granted and the channel identified by notification_channel_id exists.
• Ensure that timestamp is newer than the last processed event and that notification_id has not changed. For broadcasts, also verify the device’s subscription to topic_name.
• Confirm that the app is not force-stopped.
• Confirm that the device has network connectivity.
• Test on multiple devices to rule out device-specific issues.
• Verify that the device runs Android 16.1 (API level 36.1) or later and the app uses targetSdk 36.
• Check that content_state keys and value types match the app’s style provider.

If you have completed all steps and the issue remains unresolved, contact Adobe Customer Care with:

Required information:

• Campaign ID and name
• Profile namespace and ID
• notification_id and event_type from the API payload; for broadcasts, also include topic_name and the audience ID
• Timestamps of API calls
• Campaign report screenshots showing Sending Statistics, Error Reasons, and Excluded Reasons
• Relevant profile message.feedback events, including FCM error codes and messages
• Assurance session details and relevant event screenshots
• API request payload and response, with credentials and device tokens redacted
• Android package name, Firebase project and sender ID, and FCM credential configuration details; do not include private keys
• Android OS version, device model, notification permission status, and relevant app logs

1. Open your API Triggered Marketing Campaign in Journey Optimizer.

2. Navigate to the Audience section and verify:

   • An audience is selected for the campaign.
   • The audience ID matches the one used in your API payload.
   • The audience contains the expected profiles.

3. Navigate to the Actions section.

4. Check the Live activity configuration:

   • The configuration must be set for the iOS app with the correct bundle identifier.
   • The Activity type must match the attributes-type in your API payload. For example, if your payload contains "attributes-type": "AirplaneTrackingAttributes", the campaign must specify this same Activity type.

The broadcast payload structure differs from unitary campaigns. Verify that your payload follows the correct broadcast format.

Required fields for broadcast:

{
   "campaignId": "878a11d4-b519-47bd-8313-fecfee19857b",
   "audience": {
      "id": "8c3dbdea-2957-401f-acf0-3966fba1601e"
   },
   "context": {
      "requestPayload": {
         "aps": {
            "input-push-channel": "FEt0NgvLEfEAAOqA6AXdIQ==",
            "content-available": 1,
            "timestamp": 1771829292,
            "event": "start",
            "attributes-type": "AirplaneTrackingAttributes",
            "content-state": { ... },
            "attributes": { ... }
         }
      }
   }
}

Common payload issues:

Critical broadcast-specific fields:

• input-push-channel:

  • Required for all broadcast Live activities.
  • Serves as a unique identifier for this specific broadcast instance.
  • All profiles in the audience receive Live activities linked to this channel.
  • Must match the channelID in liveActivityData.channelID (see step 3).
  • Must be created for the appID in the Apple Developer Portal by your team.
  • Only channels created for the specific appID can be used for broadcasting Live activity on that app.

• audience.id:

  • Must reference a valid audience segment created in Adobe Experience Platform.
  • All profiles in this audience are targeted for the Live activity.
  • The audience must be activated and contain profiles with valid liveActivityPushNotificationDetails.

Always use the latest timestamp:

• The timestamp field must always be the current Unix epoch time (in seconds) for every API call.
• This requirement applies to all event types: start, update, and end.
• Critical for updates/end: Using stale timestamps causes update and end requests to fail.
• Generate a fresh timestamp for every broadcast API call.

Optional fields:

• dismissal-date: Unix epoch time for auto-dismissal (only relevant for end events)
• alert: Object with title and body for notification

Refer to the Adobe Journey Optimizer Messaging API documentation for complete API specifications.

Ensure that the payload fields match your iOS app’s ActivityAttributes implementation, and that the input-push-channel matches the channelID in liveActivityData.

1. Review your iOS ActivityAttributes definition.

Your custom ActivityAttributes struct must implement Adobe’s LiveActivityAttributes protocol:

struct AirplaneTrackingAttributes: LiveActivityAttributes {
   public struct ContentState: Codable, Hashable {
      var journeyProgress: Int
   }

   // Adobe SDK requirement
   var liveActivityData: LiveActivityData

   // Your custom attributes
   var arrivalAirport: String
   var departureAirport: String
   var arrivalTerminal: String
}

1. Map iOS fields to broadcast API payload.

Include content-state for all event types. Include attributes, including liveActivityData.channelID, for start events only:

{
   "aps": {
      "input-push-channel": "FEt0NgvLEfEAAOqA6AXdIQ==",
      "event": "start",
      "timestamp": 1771829292,
      "attributes-type": "AirplaneTrackingAttributes",
      "content-state": {
         "journeyProgress": 0
      },
      "attributes": {
         "arrivalAirport": "DEL",
         "departureAirport": "MUM",
         "arrivalTerminal": "T1",
         "liveActivityData": {
            "channelID": "FEt0NgvLEfEAAOqA6AXdIQ=="
         }
      }
   }
}

Critical: input-push-channel must match channelID

• The input-push-channel value at the root of aps must exactly match the channelID in liveActivityData.
• In the example above, both values are "FEt0NgvLEfEAAOqA6AXdIQ==".
• This matching links the broadcast instance to the Live activity data.
• A mismatch causes delivery failures.

Key validation points:

• Include all ContentState fields in content-state for all event types.
• Include all custom LiveActivityAttributes fields in attributes for start events only.
• For start events, liveActivityData.channelID must match input-push-channel.
• Field names are case-sensitive and must match exactly.
• Data types must match (String, Int, Bool, nested objects, etc.).
• For update/end events, use the same input-push-channel as the original start event.

Common mistakes:

Verify API execution and payload delivery using Assurance:

1. Open your Assurance session on a test device that is part of the audience.

2. Execute the broadcast API call.

3. In the Event List, look for:

   • Campaign execution events.
   • Live activity delivery events.
   • Error events indicating payload validation failures.

4. Inspect event payloads to confirm:

   • The payload was processed correctly.
   • The input-push-channel is present.
   • No validation errors occurred.
   • Live activities were sent to APNs for audience members.

1. Open your API-triggered Marketing campaign in Journey Optimizer.

2. Navigate to the Audience section and verify:

   • An audience is selected for the campaign.
   • The audience ID matches the one used in your API payload.
   • The audience contains the expected profiles.

3. Navigate to the Actions section.

4. Check that the Live activity configuration targets the correct Android package and uses the matching FCM credentials. Android does not use an Activity type or attributes-type field.

Android broadcasts use an FCM topic. Include audience.id and place the fcm object under context.requestPayload, rather than under an individual recipient.

Broadcast start payload example:

{
   "requestId": "your-request-id",
   "campaignId": "your-marketing-campaign-id",
   "audience": {
      "id": "your-audience-id"
   },
   "context": {
      "requestPayload": {
         "fcm": {
            "topic_name": "flight_DL321",
            "notification_id": "flight-DL-321",
            "notification_channel_id": "live_updates_channel",
            "timestamp": 1771829292,
            "priority": "PRIORITY_HIGH",
            "event_type": "start",
            "title": "Flight DL-321",
            "body": "Boarding starts shortly",
            "critical_text": "25 min",
            "content_state": {
               "custom_key_template_type": "progress",
               "custom_key_journey_start": "DEL",
               "custom_key_journey_progress": 10,
               "custom_key_journey_end": "MUM"
            }
         }
      }
   }
}

Replace the sample timestamp with the current Unix epoch time in seconds. Adapt the content_state keys to your app’s style provider.

Common payload issues:

Critical broadcast-specific fields:

• topic_name: Identifies the FCM topic subscribed to by the target devices. Include the same non-empty value in every start, update, and end request.
• audience.id: Identifies the campaign’s audience in Adobe Experience Platform. Verify its membership and sample profiles for valid pushNotificationDetails.

Timestamp and optional fields:

• Generate a fresh timestamp in epoch seconds for every event, and ensure that it is strictly greater than the last value for the same topic. Older or equal values are ignored.
• when optionally sets the notification’s displayed time in epoch seconds. It does not control message ordering.
• For event_type: "end", dismiss_after optionally specifies how many seconds the completed activity remains visible before removal. It is a duration, not an epoch timestamp.

Refer to the Adobe Journey Optimizer Messaging API documentation for complete API specifications.

1. Confirm that the test device subscribes to the exact topic specified in topic_name, using FirebaseMessaging.getInstance().subscribeToTopic(topic).
2. Verify that the subscription succeeds and that the app reports it through the topic-subscription tracking API supported by its installed Adobe Live Activities extension.
3. Keep topic_name and notification_id unchanged across start, update, and end events.
4. Verify that content_state keys and value types match the app’s style provider.
5. Check that notification permissions are granted and that notification_channel_id matches a channel created by the app.

Common mistakes:

See the Android broadcast payload example for additional fields and examples.

Use Assurance on a connected Android test device that is part of the audience and subscribed to the broadcast topic.

1. Open your Assurance session before executing the broadcast API call.
2. Send start, update, and end requests with the same topic_name and notification_id and increasing timestamps.
3. In the Events list, inspect available SDK and delivery events for payload-processing errors.
4. Confirm that the payload contains the intended fcm object, topic_name, and event_type values.
5. Review campaign reports and available message.feedback events to confirm FCM delivery outcomes. The Android serviceProvider value is fcm.
6. If FCM accepts the message but the device does not render the activity, inspect topic subscription, notification permissions, channel configuration, and app logs. Provider acceptance does not confirm device rendering.