Getting Started

Install the package with Composer and publish any provided configuration:

composer require <vendor>/<package>
php artisan vendor:publish --provider="<Vendor>\<Package>\<PackageServiceProvider>"

Configure your Android push credentials in config/ or .env as documented by the package. Then start with the simplest use case: sending a notification to a single device token.

use Davibennun\LaravelPushNotification\Facades\PushNotification;

PushNotification::app('android')
    ->to('DEVICE_TOKEN')
    ->send('Hello from Laravel');

First places to look:

The package README for credential setup and facade usage.
src/AndroidPush.php for Android-specific behavior, including the new chunk-size constant.
The published config file for app/environment definitions.
Existing tests or examples for payload structure and response handling.

As of 1.0.11, Android pushes to multiple tokens are automatically split into chunks of 750. This is an internal transport detail for most callers, but it changes how many upstream requests are made and how responses should be interpreted.

Implementation Patterns

Single-device sends

Use the fluent API for transactional or user-specific notifications:

PushNotification::app('android')
    ->to($user->device_token)
    ->send('Your order has shipped');

Multi-device sends

Pass an array of tokens. The package will split Android recipients into chunks of 750 automatically:

PushNotification::app('android')
    ->to($tokens)
    ->send('Maintenance begins at 22:00 UTC');

Do not manually chunk at 750 unless you need custom retry, logging, or partial-failure handling. Let the package handle transport chunking, and handle failures at the chunk level if you need per-batch visibility.

Queue large sends

For large audiences, dispatch the send from a queued job rather than inside a web request. This avoids request timeouts and makes retries explicit:

SendAndroidPush::dispatch($tokens, $message);

Inside the job, keep the package call simple and add your own logging around the number of tokens and chunks:

$chunks = array_chunk($tokens, 750);

foreach ($chunks as $index => $chunk) {
    Log::info('Sending Android push chunk', [
        'chunk' => $index + 1,
        'count' => count($chunk),
    ]);

    PushNotification::app('android')
        ->to($chunk)
        ->send($message);
}

This pattern is useful when you want per-chunk retries or metrics. If you rely on the package’s built-in chunking, log the total recipient count before the call instead.

Payload customization

Use the package’s payload methods for title, body, sound, badge, data, and platform-specific options. Keep custom data small and serializable. For Android, remember that data payloads and notification payloads behave differently depending on whether the app is foregrounded, backgrounded, or killed.

Testing

Mock the underlying HTTP client or facade so tests do not hit FCM/GCM. Assert:

The correct app/environment is selected.
The token list is passed correctly.
The message and payload are present.
Your application handles chunk-level failures.

For integration-style tests, use a fake HTTP client and assert the number of requests when sending more than 750 tokens.

Gotchas and Tips

Chunking changes response handling. Prior to 1.0.11, a multi-token Android send may have produced a single upstream request. Now it produces multiple requests in chunks of 750. If your code parses the return value as one response, update it to handle multiple chunk responses or handle chunking yourself.
750 is a code constant, not a config value. The chunk size is defined on the AndroidPush class. Changing it requires a code change, not a config edit. Treat it as an implementation detail unless you have a strong reason to override it.
Partial failures are possible. One chunk can succeed while another fails. If delivery guarantees matter, implement per-chunk retries and idempotency at the application level.
Retries can duplicate notifications. If a chunk request times out after the provider accepted it, a retry may deliver duplicates. Use collapse keys, notification IDs, or application-level deduplication where appropriate.
Token hygiene matters. Remove invalid or unregistered tokens based on provider responses. Large sends amplify bad-token noise and cost.
Queue timeouts and memory. Sending tens of thousands of tokens inside one job still means many HTTP requests. Monitor job duration, set sensible timeouts, and consider splitting work across multiple jobs by audience segment.
Observability. Log total recipients, chunk count, and failure counts. The chunk size of 750 is a useful unit for metrics and alerting.
Provider limits. The 750 chunk size stays under common legacy Android push limits, but always confirm current FCM/GCM quotas and payload-size limits for your account and transport.
Extension points. If you need custom chunking, retry policy, or response parsing, wrap the package call in your own service rather than scattering chunk logic across controllers and jobs.

Push Server Laravel Package