Battery Optimisation and Doze Mode in TWAs

Progressive Web Apps running inside a Trusted Web Activity (TWA) rely entirely on the underlying web rendering engine to execute JavaScript, manage Service Workers, and fetch network assets. While this architecture allows developers to maintain a single web codebase, it introduces specific challenges on the Android operating system, particularly concerning power management, battery optimisation, and resource allocation.

Modern versions of Android place strict limitations on applications operating in the background to prolong battery life. These constraints, collectively known as Doze Mode and App Standby, can severely impact how your TWA app handles background tasks, schedules synchronisation, or maintains web push notification listeners. Understanding these power-saving states is crucial for building reliable, store-ready applications.

How Doze Mode Affects Trusted Web Activities

Doze Mode reduces battery consumption by deferring background CPU and network activity for all applications when a device is unused for a long period, is stationary, and has the screen turned off. Doze Mode operates in two distinct phases: Light Doze and Deep Doze.

During both phases of Doze, the operating system groups application requests and processes them only during brief window opportunities called maintenance windows. For a TWA developer, this creates several challenges:

• Service Worker Suspensions: Service Workers running in the background are put to sleep, meaning background tasks will stop executing completely during Doze phases.
• Network Access Restrictions: The underlying browser engine is blocked from accessing the network, meaning any active fetch requests will fail or hang until the next maintenance window.
• Alarms and Timers: Standard JavaScript intervals like setInterval or setTimeout are throttled or paused entirely when the screen is turned off.

When a maintenance window occurs, the operating system temporarily restores network access and allows deferred tasks, syncs, and service worker events to run. Once the window closes, the system enters Doze once again, restricting background processes for progressively longer durations.

Understanding App Standby Buckets

In addition to Doze Mode, Android uses machine learning to classify applications into priority groups known as App Standby Buckets. The bucket your app is placed in determines how often it can run background tasks and receive messages when not actively in use.

Android dynamically moves apps between these buckets based on user engagement. The main buckets and their typical background access rules are outlined below:

For a newly installed TWA app, the initial placement is typically in the Working Set or Active bucket. However, if the user does not open the app frequently, Android will demote it to the Frequent or Rare buckets, which drastically reduces the execution window for your Service Worker background tasks.

Impact on Web Push and Background Sync

Because TWAs run on top of Chrome's engine, Web Push Notifications are delivered via Google Cloud Messaging (GCM) or Firebase Cloud Messaging (FCM). These notifications are highly integrated into the Android OS, allowing your app to receive push messages even if it is currently in a restricted App Standby Bucket or if the device is in Doze Mode.

However, processing background data alongside these notifications is restricted. When a push notification arrives while the device is in Deep Doze, your Service Worker is awakened briefly to process the message and display a visual notification. If your Service Worker attempts to perform complex operations, like downloading large files or querying remote APIs during this brief wake period, the OS may terminate the process mid-execution to protect the battery.

Similarly, the Periodic Background Sync API, which allows web apps to fetch fresh content in the background, is heavily affected by Standby Buckets. In the Rare bucket, periodic sync requests may be delayed by several hours, or dropped completely, until the user opens the application again.

Strategies to Manage Battery Restrictions

While you cannot bypass Android's system-level battery optimization policies, you can design your PWA to work gracefully within these limits. Implementing the following techniques will help preserve app functionality without draining the user's device:

1. Use the Sync Manager for Critical Actions

Instead of relying on standard network calls for critical data uploads (like saving form submissions or processing in-app actions), use the background Sync API. This ensures that if the device goes offline or enters Doze Mode, the upload task is queued and automatically executed by the browser engine as soon as the system enters a maintenance window or reconnects to a stable network.

2. Handle Graceful Degradation of Real-Time Features

If your web application relies on continuous WebSocket connections for real-time updates (such as chat apps or live dashboards), assume these connections will be severed when the screen is turned off. Design your application to cleanly disconnect when the page visibility API detects the app has been hidden, and automatically re-establish the connection and fetch missed data upon resume.

3. Instruct Users to Disable Optimisation for Critical Workloads

If your application performs highly critical background tasks that must never be delayed—such as medical tracking, continuous GPS navigation, or safety monitoring—you can guide users to manually exempt your app from Android's battery optimizations. This is done by navigating to Android Settings, selecting your app, and changing the battery configuration from Optimised to Unrestricted.

Note that Google Play enforces strict guidelines regarding which applications can prompt users for this exemption. Apps that do not require continuous background execution as a core feature may be subject to removal or rejection during the store review process if they request these exemptions unnecessarily. The standard 25 USD developer registration fee is non-refundable, so ensuring policy compliance before submission is essential.

Designing a Resilient User Experience

By understanding how the Android operating system manages device power, you can design your Trusted Web Activity to survive Doze Mode and low-power states. Keeping your background payloads lightweight, utilizing the proper background synchronization APIs, and relying on high-priority web push protocols will ensure your converted PWA remains reliable and performant under all battery conditions.