The Android IRS: How Google once tried to tax battery-sucking background apps

There are three things that are certain in life: death, taxes, and Google restricting background work. With every new Android release, Google seemingly further restricts what apps running in the background can do. This is understandable because battery power is a finite commodity on Android phones, so allowing apps to do whatever they want whenever they want would be detrimental to battery life. To prevent rogue applications from draining your phone’s battery, the Android OS implements a number of battery management tactics to control when apps can run and how long they can run.

Apps that need to perform critical, real-time tasks like downloading a file, tracking a run, or playing music can create a foreground service, but in order to do so, they must show a notification so users are aware. Instead of creating a foreground service, Google recommends most developers use APIs like JobScheduler and AlarmManager (or a higher-level wrapper, like WorkManager) to queue tasks in the background.

Based on the API that’s used and the parameters that are sent, Android will execute tasks at or near a set time (AlarmManager) or at a time that is optimal for the device’s battery (JobScheduler). The problem is that while the OS does intelligently decide when to run tasks, it does not intelligently quantify the actual battery cost of those tasks or limit the total volume of work accordingly. Arbitrary limits (like 150 jobs per app) still allow for significant power use, consuming a scarce commodity — battery power.

In an attempt to address this limitation and maximize battery life, Google envisioned The Android Resource Economy (TARE), a major reworking of how the system manages background work. TARE sought to apply macroeconomic principles to resource management, treating battery power as a finite commodity that must be allocated efficiently. It quite literally creates a virtual economy, complete with currency, costs, wages, and regulations, to ensure that the finite supply of battery power is efficiently allocated to the tasks that provide the most value to the user.

Although Google scrapped TARE last year, I thought it would be interesting to explore what might have been. In this post, I’ll be diving deep into TARE and explain exactly how Google planned to tax battery-draining Android apps.

You’re reading the Authority Insights Newsletter, a weekly newsletter that reveals some new facet of Android that hasn’t been reported on anywhere else. If you’re looking for the latest scoops, the hottest leaks, and breaking news on Google’s Android operating system and other mobile tech topics, then we’ve got you covered.

Subscribe here to get this post delivered to your email inbox every Saturday.

The Android Resource Economy: A Non-Central Banker’s Retrospective

The Android Resource Economy significantly tweaks how tasks are executed when they’re queued via the AlarmManager and JobScheduler APIs. It creates a virtual economy managed by a central authority known as the IRS, short for the Internal Resource Service (an obvious play on the American Internal Revenue Service). The IRS acts as both a central bank and a regulatory body, determining the money supply, setting prices, and enforcing regulations.

Under TARE, Android utilizes a virtual currency called “Android Resource Credits” (ARCs). Apps need a balance of ARCs to “purchase” the ability to run background tasks. (Android also used “Cakes” as a smaller denomination, where 1,000,000,000 Cakes — a Giga-Cake — is equal to 1 ARC. Yes, this is a dual-layered joke invoking the “cake is a lie” meme and the “let them eat cake” quote.)

The Economic Model: CTP vs. Price

TARE introduces a sophisticated model that separates the (battery) cost of an action from the price (in ARCs) charged to the app.

• Cost to Produce (CTP): This is the estimated cost (in ARCs) to the system — the battery drain equivalent — to execute the action.
• Price: This is the amount (in ARCs) the app is actually charged for the action.

In TARE’s ideal market, the Price is generally greater than or equal to the CTP. The system aims to maximize its “profit” (Price minus CTP). By prioritizing actions with higher Prices, the system theoretically prioritizes tasks providing more user value.

The CTP and Price aren’t static; the IRS applies “Modifiers” based on the device’s state. For example, costs might increase when battery saver mode is turned on or decrease when the phone is charging. Crucially, the app’s process state matters; if an app is the TOP app (i.e. actively being used), the Price is often reduced to zero.

When battery saver is turned on, the Price of an action is increased to accommodate the user’s preference for maximized battery life.

Earning Credits: Wages and Stimulus

Apps maintain a balance of ARCs in their Ledger, which is managed by the IRS and its enforcement arm, the Agent. There are two main ways apps earn credits: Regulations (government stimulus) and Rewards (wages).

Regulations are interventions by the IRS. When an app is installed, it receives a “Birthright” — an initial balance. If an app falls below a minimum required balance, the IRS provides “Basic Income” when the device is charging, ensuring apps aren’t permanently bankrupt.

Rewards are earned through positive user engagement. The system grants ARCs when the user opens the app (an ongoing reward per second), interacts with an app’s notification or widget, or even just views a notification. Apps can accrue ARCs up to a “Maximum Satiated Balance” to prevent hoarding.

TARE rewards apps with ARCs when the user interacts with their notifications.

Spending and Enforcement

Excluding “VIPs” (Very Important Packages — such as the OS itself, the TOP app, or apps exempted from battery restrictions), apps have to spend ARCs for all actions.

Before starting a task, the system checks if the app could afford an “Action Bill.” This bill includes the Price to start the task plus an estimated runtime (e.g., 30 seconds). If the app’s balance drops below the required amount while a job is running, the Agent will notify the system, which immediately stops the job.

When an app runs out of ARCs to spend, it is effectively bankrupt and cannot queue any more background work through AlarmManager or JobScheduler. TARE encourages apps to be designed to choose their actions carefully based on their available ARCs, as the system is designed to maximize its own “profits” by prioritizing tasks with a higher Price.

The Consumption Limit and Regulation

TARE doesn’t just manage individual app balances; it also manages the global supply of resources available, known as the “Consumption Limit.”

This introduces a crucial dual-check: an action can only proceed if the app can afford the Price and the system’s remaining Consumption Limit can cover the CTP. When an app runs a task, the Price is deducted from the app’s Ledger, and the CTP is deducted from the Consumption Limit.

When the battery is “satiated” (full), the Consumption Limit is at its maximum. As the battery level drops, the available resources are immediately reduced proportionally. The reason for tying the number of ARCs to the device’s battery level is that power consumption is more acceptable when the battery level is higher but less so when the device is about to run out of battery.

The Consumption Limit (i.e. the total amount of ARCs in circulation) is at its maximum when the device is fully charged.

The IRS also actively manages the economy through regulation:

• Wealth Reclamation (Taxation): To prevent apps from hoarding credits, the IRS periodically reclaims a percentage of unused ARCs from apps that haven’t been used recently (defaulting to 3 days).
• Dynamic Tuning: The IRS doesn’t just rely on fixed limits. It uses an “Analyst” component to track historical battery drain against a target rate (e.g., 40 hours of background life). If the battery is draining too slowly, the IRS might increase the Consumption Limit (i.e. “Quantitative Easing”); if the battery is draining too quickly, it might decrease the limit.

A TARE-ible idea?

TARE was a short-lived experiment that Google scrapped last year with the release of Android 15. It was never rolled out on any devices and could only be manually enabled in Android’s Developer Options. We don’t know why Google ultimately scrapped this idea as the commit removing its code doesn’t mention a reason. It’s possible that TARE was simply too ambitious; tuning a virtual economy to match real-world battery behavior is incredibly complex. Given its complexity and far-reaching effects on apps, developers would need a lot of time to evaluate and make changes to support the new system, which would be a significant burden for smaller teams.

Want more?

Authority Insights is more than a newsletter — it’s the hub for all our best content. If you care about Android, you won’t want to miss any of our other exclusive reports.

Don’t have time to read them all? Subscribe to our Authority Insights Podcast to hear me and my co-host, C. Scott Brown, break down our top stories of the week.