Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Android widgets are host-rendered, miniature views of an app—not the app running continuously on your home screen. The launcher asks the app for widget content, displays that content, and requests another version when an allowed trigger occurs. A periodic request through updatePeriodMillis cannot be configured below 30 minutes, and even that interval is a scheduling request rather than a guarantee. User interaction, foreground use, push messages, broadcasts, and deferred background work can produce faster updates, but Android may delay any background operation to protect battery life.
What an Android widget actually is
Android defines an app widget as a “miniature app view” that can be embedded in another app, such as the home-screen launcher. That distinction explains most apparent refresh problems. When you open an app, its activities, services, database access and network code can run as part of a normal foreground session. A widget is different: the launcher or another widget host owns the visible surface, while the app supplies metadata, content and update callbacks.
The result is closer to a hosted snapshot than to a permanently running copy of the app. The host keeps displaying the last widget view it received. The application must be called back, obtain current data and send a replacement view before the display changes. If no permitted callback occurs, the launcher has no reason—or permission under the platform’s power rules—to fetch newer information.
Why the app can be newer than its widget
Opening an app usually gives it a foreground opportunity to query its data source and redraw immediately. A widget may still show an older weather reading, calendar item or news headline because it is waiting for a scheduled request or another trigger. The two surfaces can therefore be temporarily out of sync without either one being broken.
This separation also applies to widgets built with Jetpack Glance. Glance composes content and translates it into RemoteViews that are sent to the host. The widget’s process is separate from the app’s normal UI process and can be destroyed at any time. A reliable implementation must be able to rebuild the widget from durable application data whenever the host asks for it; it cannot depend on variables that happened to remain in memory.
The periodic refresh limit: what 30 minutes means
The AppWidgetProviderInfo XML attribute updatePeriodMillis tells Android when to request periodic widget updates. Android’s advanced-widget documentation states that this mechanism “doesn’t support values of less than 30 minutes.” A developer who enters a shorter value is not creating a dependable five- or ten-minute timer; the framework’s periodic path has a documented 30-minute floor.
Thirty minutes is also not a promise that a widget will redraw exactly every 30 minutes. It is a request interval. Launcher behavior, device power management, the app’s ability to run, network availability and the work performed by the provider can all move the observed update later. Android recommends infrequent updates because waking an application and performing network or database work consumes battery.
For that reason, a widget configured for a 30-minute period might remain unchanged longer when a phone is idle or power restrictions are active. The platform is balancing freshness against standby time, not reporting that the app has failed.
Four ways a widget can refresh
Periodic scheduling is only one update path. Android widgets can receive newer content through several triggers, each with a different freshness, power and workload profile.
1. Periodic framework requests
The host asks the provider for an update according to updatePeriodMillis. This is predictable in intent and suitable for information that does not need to be current every few minutes, such as a daily summary or a slowly changing status. The 30-minute minimum applies specifically to this framework mechanism, and system power policies can still defer execution.
2. User interaction
A tap or other interaction with the widget can trigger an immediate update. This is useful for controls and views where the user has just expressed interest: a refresh action, a next-item button or a toggle can cause the provider to rebuild the displayed view. It is event-driven, so it can be more responsive than waiting for the next periodic request, but it requires an actual interaction.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
3. Foreground app activity
When the user is actively using the app, the app can update its widget as part of that work. A weather app, for example, may retrieve a current observation when opened and then send that information to its widget. The widget becomes current because the app already has a foreground execution opportunity, not because the widget itself has become a continuously running activity.
4. Messages and broadcasts
An app that is already responding to an FCM message or another broadcast can request a widget update. This is an event-driven design: a new server event or system event supplies a reason to refresh rather than waking the widget on a fixed timer. The timing depends on whether the message or broadcast is delivered and whether Android permits the app to complete its work at that moment.
5. Deferred work with WorkManager
For work that must run while the app is not active, developers can use WorkManager. Android’s guidance gives a 15-minute cadence as an example of a schedule WorkManager can represent. That example is not a guarantee that every widget will refresh every 15 minutes. WorkManager jobs remain subject to battery optimization, network constraints and other power restrictions, and frequent work can drain the battery.
WorkManager is especially appropriate when refreshing requires a longer operation, such as a network request followed by a database query and data transformation. The worker performs that work and then asks the widget provider to publish the resulting view. The widget should not be expected to perform a long-running operation directly in a broadcast callback.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Why Android delays background widget work
Background execution limits are a major reason a widget can appear stale. Broadcast receivers run under those limits. If the system is busy or resources are constrained, invocation can be delayed. A receiver that spends too long performing work can also be treated as non-responsive.
Rank #4
Complex database queries and network lookups are therefore poor candidates for a receiver’s immediate callback. Android recommends moving that work to WorkManager and calling the widget update after the work finishes. This separates the short notification that an update is needed from the potentially slow operation that obtains the data.
The same policy explains why a nominal schedule does not equal a stopwatch. A phone in standby, a restricted app, unavailable network or competing system work can postpone the fetch. A widget may eventually catch up without any change to its code or layout.
Comparing the refresh approaches
| Approach | Trigger | Freshness profile | Battery and work profile | Important limitation |
|---|---|---|---|---|
Periodic updatePeriodMillis |
Framework request from the host | Predictable in intent, with a 30-minute minimum for this mechanism | Designed for infrequent, relatively light updates | It is a request, not an exact execution time; power policy may defer it |
| User interaction | Tap or other widget action | Immediate when the user interacts | Work occurs because there is a user-driven reason | No interaction means no event-driven refresh |
| Foreground app use | The user opens or uses the app | Can be current while the app is active | Uses an existing foreground execution opportunity | Does not keep the widget current after the app is closed |
| FCM or broadcast | Incoming message or system/app broadcast | Responsive when delivery and execution are allowed | Event-driven; cost depends on the work started | Delivery and background limits can delay the callback |
| WorkManager | Deferred or repeating background work | Suitable for scheduled or longer refresh jobs | Can perform heavier work, but frequent jobs consume battery | Schedules remain subject to power, network and system constraints |
What the behavior looks like in common widgets
Weather
A weather app can show a new observation immediately after you open it. Its home-screen widget may continue showing the previous observation until a periodic request, a permitted background job or an app event causes the provider to fetch and publish another view. A 15-minute WorkManager example should be read as scheduling guidance, not as a promise that the temperature changes on that exact cadence.
Calendar
A calendar widget may change after you create or edit an event in the app because foreground activity can publish the new data. If an event is changed elsewhere, the widget depends on the app receiving a relevant event, running allowed background work or reaching its next permitted periodic update.
News
A news app can retrieve fresh headlines whenever it is opened, while the widget retains its last host-rendered list in between updates. Frequent background polling would make the headlines fresher but would also wake the device and use more network and battery resources, so Android’s scheduling rules favor deferred or event-driven work.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How to diagnose a widget that looks stuck
Start by separating a data problem from a scheduling problem. The following checks do not force Android to violate its power policy; they help identify which update path is available.
- Open the app and check the same information. If the app also shows old data, the source, account or network operation is stale. If the app is current but the widget is not, the issue is the widget’s update path or its last published view.
- Interact with the widget. Use its available refresh control or another action. A response after interaction indicates that an event-driven path works, while a lack of response points to the provider’s update or data-loading work.
- Allow time for the documented schedule. A periodic setting below 30 minutes cannot make the framework path run that often, and a 30-minute request can be deferred. Judge behavior over a longer interval rather than expecting a precise minute.
- Consider background conditions. Standby, battery-saving policy, restricted execution, unavailable network and system load can all delay broadcasts or WorkManager jobs. These conditions explain intermittent lag even when the app works correctly in the foreground.
- Rebuild from durable data when developing. A Glance or other widget process can be destroyed. Store the data needed to render the view in durable application storage and make the provider able to reconstruct the widget whenever it is called; do not rely on in-memory state surviving.
Design guidance for developers
Choose the trigger to match the information
Use infrequent periodic updates for content whose value changes slowly. Prefer an event-driven update when a user action, foreground transaction, FCM message or broadcast already provides a reason to refresh. Use WorkManager when obtaining the data is deferred, lengthy or must occur while the app is inactive. This division limits unnecessary wakeups while preserving responsiveness where it matters.
Free tools Windows power users keep installed
One-click scans. No signup required.
Keep the provider callback short
Broadcast receivers should not be burdened with complex database or network operations. Hand that work to WorkManager, then publish the widget view after the worker completes. A short callback is less likely to be treated as non-responsive and gives Android a clearer boundary between receiving an event and doing substantial work.
Treat every render as a rebuild
Because the widget process can disappear, every update must be able to start from durable application state. Jetpack Glance’s translation to RemoteViews does not change that lifecycle rule. Keep the authoritative data outside transient widget memory, retrieve it when needed and generate a complete view for the host.
The practical answer to “How often do Android widgets refresh?”
There is no single refresh interval for all Android widgets. The periodic framework route has a documented minimum of 30 minutes, but a widget can update sooner after interaction, during foreground app use or in response to an FCM message or broadcast. WorkManager can represent schedules such as 15 minutes for deferred work, yet power management and execution constraints can delay the job. The visible interval is therefore the result of the widget’s implementation, its available triggers and the device’s current permission to run background work.
When an app shows newer information than its widget, the usual explanation is not that the widget is defective. The app had a foreground opportunity; the host-rendered widget is waiting for its next permitted update. Designing and troubleshooting it successfully means treating freshness, battery cost, trigger availability and work duration as one scheduling decision rather than assuming the home screen is a continuously running app.
Recommended Free Tools
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
