Assign one display path to each push payload and app state

Name the configuration before describing its behavior

Firebase's Android receive guide, checked November 7, 2026, explicitly separates legacy AndroidConfig handling from AndroidConfigV2. The familiar foreground/background routing table applies to the legacy path; the newer path describes automatic notification display in both states unless explicitly silenced by client code. Do not apply either description to an app without confirming its deployed configuration.

Ask the developer to record SDK version, server payload path and supported app releases. Identify whether the message is notification-only, data-only or mixed. Keep iOS and web implementations as separately verified rows rather than copying the Android model. The campaign team's practical question is which component turns the approved payload into the public message in each supported state.

Write the expected handoff for each state

For foreground, background and relevant launch states, identify the callback or system presentation expected by the implementation owner. State when custom data becomes available and which component uses it. A campaign can look correct in the notification tray while losing the product reference needed after a tap.

Draw a simple event trace from receipt through display to interaction. Use harmless fictional product identifiers, never credentials or private customer data. Ask which app code creates a local notification and whether the SDK also creates one. If two components both believe they own display, the customer can receive duplicates from a single accepted request. Resolve ownership explicitly rather than hiding one duplicate by changing unrelated campaign frequency settings.

Test absence, duplication and state transitions

Use the actual supported builds in controlled test environments. Send the same approved fixture with the app active, backgrounded and reopened through the supported route. Verify title, body, action reference and the number of visible presentations. Observe transitions near receipt, since a device that changes state can expose a different code path than a stationary test.

Firebase's message-type guidance distinguishes SDK-handled notification content from client-handled data messages. That technical distinction does not authorize choosing a data-only workaround to evade the user's notification choices. Respect permission, channel and operating-system restrictions throughout. If data processing cannot complete within the supported lifecycle, have engineering design the permitted behavior; do not assume background code can fetch unlimited extra assets before displaying the message.

Keep acceptance attached to the configuration change

Record the tested payload revision, app version, state and observed display owner. Mark untested platform paths honestly rather than declaring the campaign universally ready. If a migration changes automatic presentation, recheck custom notification code and the interaction handoff before expanding rollout. A previously necessary manual display step may become a duplicate under a different path.

Separate transport acceptance from successful app processing and successful presentation. A provider's message identifier cannot establish that the desired callback ran or that the correct data reached the destination. When an issue occurs, supply the developer with a reproducible state-and-payload case, sanitized evidence and the expected result. The outcome is one coherent approved message through each supported state, with no invented guarantee that every device will always show it.

Make the reasoning concrete.

A fictional retailer updates its Android messaging integration. The app retains custom foreground notification creation while the new configured path also presents the notification automatically. A mixed payload carries the promoted product reference.

The retailer tests both supported release paths and resolves duplicate ownership with engineering. It does not switch message type to bypass notification controls.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Configuration

   Which SDK, server payload path and app release define this behavior?

2. Owner

   Who creates the visible notification in each state?

3. Data

   When and where does the destination reference become available?

4. Transition

   What happens if the app changes state around receipt?

5. Evidence

   Which observed result proves presentation rather than provider acceptance alone?

Watch for the wrong conclusion.

• Teaching the legacy Android state table as universal current behavior.
• Allowing SDK and app code to independently create the same notification.
• Using data messages as a workaround for user controls.

Sources & scope

Workflows, worksheets and fictional examples are original editorial analysis, not supplier implementation instructions or measured business results. Sources support only the specifically attributed platform facts. Supplier controls, contracts and local requirements can change; verify the actual placement and current provider guidance before implementation.

• Firebase: Receive messages in Android apps →Primary platform documentation · Supports: Supports explicitly dated legacy-versus-AndroidConfigV2 routing differences and callback/lifecycle boundaries; the testing matrix is editorial.
• Firebase: Cloud Messaging message types →Primary platform documentation · Supports: Supports notification/data payload distinction and implementation-scoped handling.