1# Overview 2 3Welcome to The Android Resource Economy (TARE for short). If you're reading this, you may be 4wondering what all of this code is for and what it means. TARE is an attempt to apply economic 5principles to resource (principally battery) management. It acknowledges that battery is a limited 6resource on mobile devices and that the system must allocate and apportion those resources 7accordingly. Every action (running a job, firing an alarm, using the network, using the CPU, etc.) 8has a cost. Once that action has been performed and that bit of battery has been drained, it's no 9longer available for someone else (another app) to use until the user charges the device again. 10 11The key tenets of TARE are: 12 131. Charge for actions --- when an app performs an action, reduce its access to resources in the 14 future. This should help remind everyone that everything they do has a cost. 151. Reward for good actions --- reward and encourage behavior that provides value to the user 161. Fine bad actions --- fine and discourage behavior that is bad for the user 17 18In an ideal world, the system could be said to most efficiently allocate resources by maximizing its 19profits — by maximizing the aggregate sum of the difference between an action's price (that 20the app ends up paying) and the cost to produce by the system. This assumes that more important 21actions have a higher price than less important actions and all actors have perfect information and 22convey that information accurately. With these assumptions, maximizing profits implies that the 23system runs the most important work first and proceeds in decreasing order of importance. Of course, 24that also means the system will not run anything where an app would pay less for the action than the 25system's cost to produce that action. Some of this breaks down when we throw TOP apps into the mix 26— TOP apps pay 0 for all actions, even though the CTP may be greater than 0. This is to ensure 27ideal user experience for the app the user is actively interacting with. Similar caveats exist for 28system-critical processes (such as the OS itself) and apps running foreground services (since those 29could be critical to user experience, as is the case for media and navigation apps). Excluding those 30caveats/special situations, maximizing profits of actions performed by apps in the background should 31be the target. 32 33To achieve the goal laid out by TARE, we use Android Resource Credits (ARCs for short) as the 34internal/representative currency of the system. 35 36## How do ARCs work? 37 38ARCs are required to perform any action while in the background. Some actions may have a fixed cost. 39Others may be more dynamic (some may even allow apps to bid higher ARCs for some actions to have 40them prioritized). If the app doesn't have enough ARCs, the action can't be performed. Apps are 41granted ARCs (below a certain threshold) as the device charges. Apps are also granted ARCs for 42providing user value (eg. for doing things that engage the user). 43 44ARCs will be used across the entire system as one unified concept. When an app performs an action, 45it pulls from the same account, regardless of the action. This means that apps can choose to do more 46of one action in lieu of being able to do as much of another. For example, an app can choose to use 47all of its ARCs for jobs if it doesn't want to schedule any alarms. 48 49### Scaling 50 51With the ARC system, we can limit the total number of ARCs in circulation, thus limiting how much 52total work can be done, regardless of how many apps the user has installed. 53 54## EconomicPolicy 55 56An EconomicPolicy defines the actions and rewards a specific subsystem makes use of. Each subsystem 57will likely have a unique set of actions that apps can perform, and may choose to reward apps for 58certain behaviors. Generally, the app should be rewarded with ARCs for behaviors that indicate that 59the app provided value to the user. The current set of behaviors that apps may be rewarded for 60include 1) a user seeing a notification, 2) a user interacting with a notification, 3) the user 61opening the app and/or staying in the app for some period of time, 4) the user interacting with a 62widget, and 5) the user explicitly interacting with the app in some other way. These behaviors may 63change as we determine better ways of identifying providing value to the user and/or user desire for 64the app to perform the actions it's requesting. 65 66### Consumption Limit 67 68The consumption limit represents the maximum amount of resources available to be consumed. When the 69battery is satiated (at 100%), then the amount of resources available to be consumed is equal to the 70consumption limit. Each action has a cost to produce that action. When the action is performed, 71those resources are consumed. Thus, when an action is performed, the action's CTP is deducted from 72the remaining amount of resources available. In keeping with the tenet that resources are limited 73and ARCs are a proxy for battery consumption, the amount of resources available to be consumed are 74adjusted as the battery level changes. That is, the consumption limit is scaled based on the current 75battery level, and if the amount currently available to be consumed is greater than the scaled 76consumption limit, then the available resources are decreased to match the scaled limit. 77 78### Regulation 79 80Regulations are unique events invoked by the ~~government~~ system in order to get the whole economy 81moving smoothly. 82 83# Significant Changes 84 85## Tare Improvement Proposal #1 (TIP1) 86 87The initial implementation/proposal combined the supply of resources with the allocation in a single 88mechanism. It defined the maximum number of resources (ARCs) available at a time, and then divided 89(allocated) that number among the installed apps, intending to have some left over that could be 90allocated as part of the rewards. There were several problems with that mechanism: 91 921. Not all apps used their credits, which meant that allocating credits to those packages 93 effectively permanently reduced the number of usable/re-allocatable ARCs. 941. Having a global maximum circulation spread across multiple apps meant that as more apps were 95 installed, the allocation to each app decreased. Eventually (with enough apps installed), no app 96 would be given enough credits to perform any actions. 97 98These problems effectively meant that misallocation was a big problem, demand wasn't well reflected, 99and some apps may not have been able to perform work even though they otherwise should have been. 100 101TIP1 separated allocation (to apps) from supply (by the system) and 102allowed apps to accrue credits as appropriate while still limiting the total number of credits 103consumed. 104 105## Tare Improvement Proposal #3 (TIP3) 106 107TIP1 introduced Consumption Limits, which control the total number of ARCs that can be used to 108perform actions, based on the production costs of each action. The Consumption Limits were initially 109determined manually, but could increase in the system if apps used the full consumption limit before 110the device had drained to 50% battery. As with any system that relies on manually deciding 111parameters, the only mechanism to identify an optimal value is through experimentation, which can 112take many iterations and requires extended periods of time to observe results. The limits are also 113chosen and adjusted without consideration of the resulting battery drain of each possible value. In 114addition, having the system potentially increase the limit without considering a decrease introduced 115potential for battery life to get worse as time goes on and the user installed more background-work 116demanding apps. 117 118TIP3 uses a target background battery drain rate to dynamically adjust the Consumption Limit. 119 120# Potential Future Changes 121 122These are some ideas for further changes. There's no guarantee that they'll be implemented. 123 124* Include additional components and policies for them. TARE may benefit from adding policies for 125 components such as broadcast dispatching, network traffic, location requests, and sensor usage. 126* Have a separate "account" for critical/special actions. In other words, have two accounts for each 127 app, where one acts like a special savings account and is only allowed to be used for special 128 actions such as expedited job execution. The second account would have a lower maximum than the 129 main account, but would help to make sure that normal actions don't interfere too much with more 130 critical actions. 131* Transferring credits from one app to another. For apps that rely on others for some pieces of 132 work, it may be beneficial to allow the requesting app to transfer, donate, or somehow make 133 available some of its own credits to the app doing the work in order to make sure the working app 134 has enough credits available to do the work. 135* Formulate values based on device hardware. For example, adjust the consumption limit based on the 136 battery size, or the price and/or CTP of actions based on hardware efficiency. 137* Price discovery via an auction system. Instead of just setting a fixed price that may be modified 138 by device and app states, let an app say how much it's willing to pay for a specific action and 139 then have a small auction when the system needs to decide which app to perform the action for 140 first or how much to charge the app. 141 142# Definitions 143 144* ARC: Android Resource Credits are the "currency" units used as an abstraction layer over the real 145 battery drain. They allow the system to standardize costs and prices across various devices. 146* Cake: A lie; also the smallest unit of an ARC (1 cake = one-billionth of an ARC = 1 nano-ARC). 147 When the apps request to do something, we shall let them eat cake. 148* Cost to produce (CTP): An economic term that refers to the total cost incurred by a business to 149 produce a specific quantity of a product or offer a service. In TARE's context, CTP is meant to be 150 the estimated cost t ohe system to accomplish a certain action. These "actions" are basically APIs 151 that apps use to get something done. So the idea is to define the base cost for an app to use a 152 specific API. 153* Satiated: used to refer to when the device is fully charged (at 100% battery level)