Android Resource Reliability: Token Bucket, Multi-Rate Limiting & Quota Design

Background

Android's system framework exposes numerous APIs—such as Alarm, Notification, Job, Broadcast, Receiver, and Cursor—that allow apps to trigger system operations. Misuse of these interfaces can degrade system_server performance, cause resource exhaustion, and lead to UI jank or freezes. To address this, Google has introduced several protective mechanisms at the framework level, informed by DFX (Design for X) engineering and software fault-mode analysis. This article surveys those designs.

TokenBucket — General-Purpose Token Bucket

File:

frameworks/base/core/java/com/android/internal/util/TokenBucket.java

TokenBucket implements a lightweight, lazily refilled, non-thread-safe token bucket. It is primarily used to throttle logging, metrics collection, and high-frequency system operations.

Usage Scenarios:

Network packet logging –

packages/modules/NetworkStack/src/android/net/ip/ConnectivityPacketTracker.java

APF program installation –

packages/modules/NetworkStack/src/android/net/apf/ApfFilter.java

. Allows 20 immediate updates, then refills one token every 3 seconds to prevent abnormal networks from triggering frequent APF program generation and installation.

Metrics events –

frameworks/base/services/core/java/com/android/server/connectivity/IpConnectivityMetrics.java

. Burst limit of 50 events; under sustained load, only one event per minute is allowed, protecting the metrics buffer from being saturated by a single event type.

Latency sample sampling –

frameworks/base/core/java/android/net/metrics/ConnectStats.java

MultiRateLimiter — Multi-Rate Quota Engine

File:

frameworks/base/services/core/java/com/android/server/utils/quota/MultiRateLimiter.java

MultiRateLimiter is a "multi-window rolling rate limiter." It subjects each event to multiple CountQuotaTracker instances simultaneously; an event is permitted only when all windows are below their limits.

Scenario 1: Toast Rate Limiting in NotificationManagerService

ToastRateLimits = {     3 times / 20 sec,     5 times / 42 sec,     6 times / 68 sec }

The three windows combine to create a staircase penalty: after 3 consecutive Toasts, the app must wait 20 seconds for the next; after that, wait 22 seconds more, and so on—approximately a 1.5× increasing wait—to mitigate Toast bombing ( NotificationManagerService.java).

// Check quota before showing
if (!mToastRateLimiter.isWithinQuota(userId, pkg, TOAST_QUOTA_TAG)) {
    // Over quota, reject display
}
// Record event after successful display
mToastRateLimiter.noteEvent(userId, pkg, TOAST_QUOTA_TAG);

Other Similar Designs:

DropboxRateLimiter – crash log rate limiting (

frameworks/base/services/core/java/com/android/server/am/DropboxRateLimiter.java

)

Profiling RateLimiter – multi-window quota for profiling (

packages/modules/Profiling/util/src/com/android/profiling/utils/RateLimiterBase.java

)

AppWidget ApiCounter – API call counting (

frameworks/base/services/appwidget/java/com/android/server/appwidget/AppWidgetServiceImpl.java

)

SELinux RateLimiter – QPS push limiting (

frameworks/base/services/core/java/com/android/server/selinux/RateLimiter.java

)

Counting Design — Resource Quotas

The principle is straightforward: count registered or requested resources and enforce a maximum.

Maximum broadcast receivers per app –

frameworks/base/services/core/java/com/android/server/am/BroadcastController.java

// Maximum number of receivers an app can register.
private static final int MAX_RECEIVERS_ALLOWED_PER_APP = 1000;

Conclusion

When designing external-facing interfaces, similar reliability considerations—rate limiting, multi-window quotas, and hard resource caps—should be applied to prevent system overload.