How to Integrate Push Notifications in Your Android App for Free

Push can bring a customer back to an order, lesson, booking, or article without waiting for that person to reopen your website. The difficult part is not writing a short message. It is connecting the app, asking for permission at the right moment, and knowing which subscriber should receive which notification.

This guide explains how to integrate push notifications in Android app for free with OneSignal. It is written for website-app owners who want a usable setup without building a notification server or writing native Android code. You will configure the app, create a test audience, connect signed-in users, and measure delivery without treating every install as the same person.

OneSignal has a free plan, but plan limits and included features can change. Check the current OneSignal pricing page before designing a high-volume campaign.

How Android Push Notifications Work

An Android push notification passes through several systems before it appears on a phone. Understanding that path makes setup and troubleshooting much easier.

The delivery path

Your app includes the OneSignal Android SDK and identifies itself with a OneSignal App ID. OneSignal uses Firebase Cloud Messaging, commonly called FCM, as the Android delivery transport. FCM routes the message to the app installation, and Android decides whether the notification can be displayed based on permission, device state, and system restrictions.

OneSignal sits above that transport. Its dashboard and APIs let you compose messages, define segments, associate devices with known users, inspect subscriptions, and automate campaigns. You do not need to maintain an app server just to send a basic campaign, although transactional messages should normally originate from a trusted backend.

An install, a user, and a push subscription are different records. One customer may use two phones. A reinstallation may create a new subscription. A person can also remain a valid app user while opting out of notifications. Do not use a push token as your permanent customer ID.

With the delivery model clear, you can prepare the identifiers and access needed for a clean integration.

Prepare OneSignal, Firebase, and Your Android App

Collect the setup details before changing app settings. Most failed integrations come from mixing credentials between projects or testing a build that does not contain the latest configuration.

Create the OneSignal app

Create an account in OneSignal, add a new app, and choose Android as a platform. Keep the generated OneSignal App ID available. It identifies the OneSignal project to the SDK and is safe to include in the client app. API keys that authorize sending are different and must remain on a trusted server.

Follow OneSignal's current Android SDK setup guide for the supported Android and SDK requirements. The guide also explains how to identify a test subscription and send the first message.

Connect Firebase Cloud Messaging

Create or select a Firebase project that belongs to the same organization as the app. Register the Android package name exactly as it appears in your build, such as com.acme.orders. Package names are case-sensitive identifiers, and a credential for another package will not repair an incorrect app configuration.

In Firebase and Google Cloud, enable the services and credentials required by OneSignal's current Android setup. Upload or enter those credentials only in OneSignal's secure configuration fields. Do not commit service-account private keys to a website repository, paste them into page JavaScript, or ship them inside the APK.

FCM is the transport beneath OneSignal on Android. You normally send through OneSignal after this connection, rather than separately sending the same campaign from Firebase.

Configure the website-based Android app

For a WebInto.app project, open the app's push notification or OneSignal configuration and enter the App ID and requested Android delivery details. Build a fresh APK after changing native push configuration. A remote website edit cannot add an SDK or native service to an already installed binary.

Install that fresh build on a physical Android device. Testing only in a browser proves that the website works, not that the Android notification service is registered.

If you have not created the app package yet, the website-to-Android app guide explains the APK, AAB, package name, and signing workflow.

Once all three projects point to the same Android app, the next task is earning notification permission.

Request Android Notification Permission Responsibly

Android 13 and later require eligible apps to obtain runtime permission before posting normal notifications. Earlier Android versions handle notification controls differently, but users can still disable the channel or app notifications in system settings.

Ask after explaining the benefit

Do not open the system permission prompt on the first frame with no context. Show a short in-app explanation at a moment when the value is obvious. An order confirmation page can offer “Get delivery updates.” A course dashboard can offer “Remind me when a new lesson is published.”

The first explanation is sometimes called a soft prompt. It should state what the user will receive, not pressure the person into accepting. If the user continues, call OneSignal's supported permission request method and let Android display the real system dialog.

Permission is not the same as subscription readiness. Check the current push subscription state after the prompt. A device can have permission but still lack a usable token because registration is incomplete, the device is offline, or configuration failed.

Handle denial without a loop

When a user declines, keep the main app functional. Do not show the system prompt on every launch. Save a local preference that records the explanation was shown, then provide a notification setting users can revisit later.

If Android no longer allows the app to display the system dialog, direct an interested user to the app's system notification settings. Explain the steps before opening settings so the transition is not surprising.

Make privacy disclosures match behavior

Your privacy policy should identify OneSignal and relevant data such as device identifiers, subscription status, app interactions, or external user IDs when you process them. Your Google Play Data safety answers must reflect the actual SDK and your use of its features.

Collect only the targeting data you need. A tag such as plan=pro can support account messaging. Uploading names, email addresses, or detailed activity without a defined purpose creates unnecessary privacy and security risk.

A respectful permission flow produces a smaller but more useful audience, which is exactly what you need for testing and targeting.

Integrate Push Notifications in Android App for Free

Now complete the connection in a controlled order. The exact screens may change, but the underlying checks remain stable.

Step 1: Install a build with OneSignal enabled

Create a new Android build after saving the OneSignal configuration. Install it directly for testing or release it to an internal Play track. Open the app at least once while connected to the internet so the SDK can initialize and register.

Check OneSignal's Audience or Subscriptions area for the device. The record may start as anonymous because the app does not yet know who is signed in. Mark your own device as a test user according to the official setup guide.

Step 2: Request permission on the device

Navigate to the place where your app explains notifications and accept the Android permission prompt. Return to OneSignal and confirm that the subscription is opted in and has a subscription ID. Allow a short registration delay before diagnosing failure.

If no record appears, verify the installed build version, package name, OneSignal App ID, Firebase credential, internet access, and device notification settings.

Step 3: Send a test notification

Create a push in OneSignal and target only the test-user segment. Use an unmistakable title such as “Test: order update,” a short body, and a deep link to a safe page in the app. Send it while the app is in the background, then repeat with the app closed.

Confirm four behaviors: the notification appears, the icon and text are correct, tapping opens the intended app page, and no duplicate notification appears. Also test the foreground state because apps may handle foreground messages differently.

Step 4: Associate the subscription with your user

After a customer signs in, call OneSignal login with a stable external ID from your own system. On logout, clear that association. Never use an email address as the external ID if an opaque account ID is available.

Website content loaded in WebInto.app can coordinate this through the native bridge. The OneSignal JavaScript bridge guide shows LOGIN, LOGOUT, and GET_USER_STATE, including how to avoid calling native methods in an ordinary browser.

await callOneSignalBridge({
  action: 'LOGIN',
  payload: { userId: 'customer_48271' }
});

Keep sending credentials off the page. The bridge links the local subscription to a user; it does not authorize your website JavaScript to send arbitrary pushes.

Step 5: Add minimal targeting data

Use OneSignal tags for durable user properties that improve relevance, such as account_type, preferred_language, or store_id. Use custom events for actions such as order_shipped or lesson_completed when the feature and plan support your intended workflow.

Treat your backend as the source of truth. Tags help messaging, but they should not become the only copy of subscription status, entitlement, or order history.

The integration is now functional. The quality of the result depends on how carefully you target and schedule messages.

Build Useful Campaigns and Measure Results

The fastest way to lose permission is to send every message to every subscriber. Define the audience, trigger, destination, and success metric before composing the copy.

Choose transactional or engagement intent

Transactional notifications report something the user expects: payment received, order dispatched, appointment moved, or security action required. They should be timely, specific, and linked to the relevant record.

Engagement notifications invite the user back: a saved item is available, a new lesson matches an interest, or a weekly summary is ready. These need frequency limits and clear opt-out controls. Do not disguise a promotion as an urgent account alert.

OneSignal segments can filter subscriptions using properties and activity. Journeys can coordinate multi-step flows where available. Read the current OneSignal tags documentation before choosing a data model.

A realistic launch example

Consider Maya, who runs a meal-prep ordering site inside a WebInto.app Android app. Her first goal is not “increase engagement.” It is to reduce missed pickup windows.

She enables OneSignal, asks for permission on the order confirmation page, and links the subscription to the customer's internal account ID. Her backend sends an order_ready event only after kitchen staff change the order status. The notification says, “Order 1842 is ready for pickup until 7:30 PM,” and opens /account/orders/1842.

Maya first targets three staff test accounts. She checks background delivery, denied permission, logout, two devices on one account, and a canceled order. Only then does she enable the event for customers. Her main metric is taps that reach the order page, but she also watches support complaints and opt-outs. That combination prevents a healthy click rate from hiding an irritating experience.

Useful campaigns need ongoing maintenance, especially when tokens, users, and app versions change.

Troubleshoot and Maintain the Integration

When a test fails, identify the failed stage instead of changing every setting at once.

Notification never arrives

Confirm that the device appears in OneSignal, is opted in, and belongs to the segment you targeted. Check Android notification permission, battery restrictions, internet access, and whether the correct build is installed. Then verify the OneSignal App ID and Firebase configuration.

Send to one known test subscription. If that works, the delivery setup is healthy and your segment rules are the likely issue.

Tap opens the wrong page

Use an HTTPS URL or deep-link format your app is configured to handle. Test authenticated and signed-out states. A link to a private order page should take a signed-out user through login and then return to that order, not leave the person on a generic home screen.

WebView apps also need link rules that keep appropriate domains inside the app. The browser, app shell, and website router must agree on the destination.

Users receive duplicates or another person's alerts

Duplicates often come from sending the same event through two systems, registering multiple handlers, or retrying without an idempotency key. Cross-account alerts usually indicate that login or logout did not update the OneSignal identity correctly.

Test this sequence explicitly: sign in as user A, receive A's message, log out, sign in as user B, then verify only B's message arrives. Review the bridge state with GET_USER_STATE during development.

Review OneSignal and Firebase release notes before SDK upgrades. Also monitor unsubscribe rate, invalid subscriptions, and notification-related support requests.

Conclusion: Integrate Push Notifications Without Native Complexity

To integrate push notifications in Android app for free, connect OneSignal to the correct Firebase and Android projects, install a fresh build, ask for permission in context, and prove delivery with a test segment. Then associate subscriptions with stable user IDs and send only messages whose timing and destination are useful.

For a website-based app, WebInto.app removes much of the native setup burden while OneSignal provides the audience and engagement layer. Review the JavaScript bridge tutorial before linking signed-in accounts. If you still need an Android package, you can start with WebInto.app and add push after the core app works.

FAQ

Can I really use OneSignal push notifications for free?

OneSignal offers a free plan, but subscriber limits, channels, analytics, and automation features can change. Check its current pricing and design your initial workflow around the included features. Firebase Cloud Messaging used as Android transport is also provided without a per-message fee, subject to service quotas.

Does Android 13 require notification permission?

Apps targeting relevant Android versions must request the POST_NOTIFICATIONS runtime permission on Android 13 and later before posting normal notifications. The SDK can expose the request, but your app should first explain the benefit. Users can still disable notifications later in Android settings.

Do I need my own notification server?

You do not need one for a manually created OneSignal campaign or basic dashboard test. Transactional notifications should come from a trusted backend that verifies the event, protects API credentials, and prevents duplicate sends. Never place a OneSignal REST API key in website JavaScript.

Can WebInto.app website code identify a signed-in OneSignal user?

Yes. WebInto.app exposes a native OneSignal bridge for login, logout, and reading user state. Call it only after confirming the native bridge exists, and use an opaque ID from your account system rather than relying on an email or push token.

Why does a test notification work on one phone but not another?

The second phone may have denied permission, missed SDK registration, joined a different segment, or installed an older build. Compare each device's subscription record and app settings before changing the campaign. Device power management and network conditions can also delay delivery.