English Original
Overview
The cached apps freezer halts execution for cached processes. As the document states, it "reduces resource usage by misbehaving apps that might attempt to operate while cached." The mechanism keeps apps in RAM but completely off the CPU. Instead of killing an app that isn't currently needed but may be needed later, Android freezes the app process so that a cold start is avoided when the app is needed again.
Freezing works by migrating processes into a frozen cgroup, which cuts both active and idle CPU consumption from cached apps. The feature can be enabled via a system configuration flag or through a developer option.
Starting in Android 14 (API level 34), the behavior becomes more robust with two specific rules:
- Cached app processes are frozen 10 seconds after they enter the cached state.
- A frozen process is immediately unfrozen upon any lifecycle event — examples given include receiving an Intent, starting a JobService, or the user resuming an Activity.
The document names two key components: ActivityManagerService manages lifecycle decisions for all app processes, while CachedAppOptimizer is the component that actually performs the freezing.
When an app process is frozen, all threads are suspended and no CPU work can occur until unfreezing. This means the app cannot perform garbage collection and cannot respond to memory trim events (ComponentCallbacks2.onTrimMemory(int)). To handle this, Android 14 introduces several accommodations:
- Apps with a visible Activity are notified of
TRIM_MEMORY_UI_HIDDEN as soon as they go to the background. Apps without a UI (such as those running a foreground service) may receive TRIM_MEMORY_BACKGROUND. Other trim events are not delivered because apps eligible for those events are expected to be frozen by that point. - Shortly after an app enters cached state, the system may ask the runtime to perform a GC in preparation for potential freezing.
- When an app process is frozen, additional memory compaction may happen, including writing dirty pages to backing storage and swapping anonymous pages to ZRAM.
- If every process belonging to an app is frozen, the system terminates any active TCP sockets the app holds. This stops the server side from sending TCP keepalive pings that would wake up the device modem.
Cached app processes unfreeze when their process state moves from cached to a higher importance level. To cut down on unfreeze events in Android 14+, the system queues context-registered broadcasts while the app is cached. These are receivers registered dynamically via Context.registerReceiver. Queued broadcasts are only delivered after the app unfreezes. In contrast, manifest-declared broadcasts (receivers declared statically in AndroidManifest.xml with <receiver>) are not queued — the system immediately unfreezes the cached app to deliver them.
System Health Impact
Android terminates the least recently used cached app process when the number of cached processes exceeds MAX_CACHED_PROCESSES. On supported devices running Android 14+, this constant is raised substantially, letting devices keep many more cached processes in RAM.
The document reports up to a 30% reduction in cold starts from maintaining more apps cached in RAM, with the reduction scaling according to total device RAM. At the same time, CPU use by cached apps is minimized, producing significant battery savings.
Freezer Exemptions
In certain conditions, an app process may enter the cached state but remain unfrozen. These are noted as implementation details subject to change in future Android releases:
- File locks: A cached process that holds a file lock blocking noncached processes will not be frozen.
BIND_WAIVE_PRIORITY bindings: App processes with incoming bindings created using Context.BIND_WAIVE_PRIORITY may become cached but stay unfrozen until all connected client processes are also cached. This exemption supports multi-process applications such as web browsers using Custom Tabs.
Implementing the Apps Freezer
The feature relies on the kernel cgroup v2 freezer. Devices shipping with a compatible kernel can turn it on.
To enable, either turn on the developer option Suspend execution for cached apps, or set the device config flag:
adb shell device_config put activity_manager_native_boot use_freezer true && adb reboot
To disable, set the flag to false or turn off the developer option:
adb shell device_config put activity_manager_native_boot use_freezer false && adb reboot
This toggle can be changed through a device configuration in a software release or update.
To override MAX_CACHED_PROCESSES (for example, setting it to 1024 for testing):
adb shell device_config put activity_manager max_cached_processes 1024
adb shell device_config set_sync_disabled_for_tests persistent
To revert the override:
adb shell device_config delete activity_manager max_cached_processes
adb shell device_config set_sync_disabled_for_tests none
The freezer does not expose official APIs and has no reference implementation client. However, it uses hidden system APIs: setProcessFrozen to freeze an individual process, and enableFreezer to enable or disable freezing globally.
Handling Custom Features
App processes are not expected to do any work while cached. Some applications, however, have custom features backed by processes that are expected to run while cached. When the freezer is enabled on a device with such apps, the cached processes get frozen, which may break those custom features.
The workaround is to change the process status to noncached before any work needs to happen. Active statuses like a bound foreground service or a foreground status will keep the app active.
Common Failure Modes
Improper IPC or task scheduling can cause app terminations or unexpected behavior when processes are frozen.
Synchronous Binder Transactions to Frozen Processes
When a client sends a synchronous binder transaction to a frozen server process, the system immediately terminates the server process. This prevents the client thread from blocking indefinitely. The client then receives a RemoteException, and any registered listeners fire (see IBinder.linkToDeath).
Root cause: This is typically a client-side bug. When a client binds to a service, the server process is bound to the client and cannot become cached before the client does (see Context.bindService). However, once the client calls Context.unbindService, the server process can become cached and frozen. If the client keeps using the cached IBinder reference after unbinding, it risks communicating with a frozen process.
The fix is for clients to discard IBinder references immediately after calling Context.unbindService.
Asynchronous Binder Transaction Buffer Overflow
When a server process receives asynchronous (oneway) binder transactions while frozen, those transactions accumulate in a per-process buffer. If too many build up while the process is frozen, the buffer overflows and the system terminates the server process.
The prevention is to avoid sending excessive asynchronous binder transactions to processes that may be cached or frozen.
Repeated Execution of Scheduled Tasks Upon Unfreezing
If an app runs repetitive tasks (via ScheduledThreadPoolExecutor.scheduleAtFixedRate or Timer.scheduleAtFixedRate), those tasks are suspended while the process is frozen. When the process unfreezes, all accumulated missed executions may run rapidly back-to-back with virtually no delay between them.
To avoid this burst, use scheduleWithFixedDelay rather than scheduleAtFixedRate for background tasks. Alternatively, use WorkManager.
Testing and Troubleshooting
Several diagnostic tools and commands are provided:
Activity Manager Commands
Use adb shell am to manually freeze, unfreeze, or compact a process:
adb shell am freeze <process>
adb shell am unfreeze <process>
adb shell am compact full <process>
Logcat Examination
View frozen/unfrozen entries each time a process migrates in or out of the freezer:
adb logcat | grep -i "\(freezing\|froze\)"
Unfreeze reason logs output enumerated values from the UnfreezeReason protocol buffer enum.
Dumpsys Inspection
Check for a list of frozen processes:
adb shell dumpsys activity | grep -A 20 "Apps frozen:"
Also check for the presence of the file /sys/fs/cgroup/uid_0/cgroup.freeze.
ApplicationExitInfo
To query why a previous process terminated, use ActivityManager.getHistoricalProcessExitReasons. If a process was terminated due to a freezer-related issue (such as receiving a synchronous binder transaction while frozen), the exit reason is ApplicationExitInfo.REASON_FREEZER.
Perfetto Tracing
Freezer-related events appear on a track called Freezer under the system_server process:
Freeze and Unfreeze slices show state transitions.updateAppFreezeStateLSP events show when the system server re-examines process attributes for freezing/unfreezing decisions.
These can be inspected in the Perfetto UI or queried via PerfettoSQL:
INCLUDE PERFETTO MODULE slices.with_context;
SELECT *
FROM process_slice
WHERE process_name = "system_server"
AND track_name = "Freezer"
AND (nameLIKE"Freeze %"ORnameLIKE"Unfreeze %");
Freezer events are also summarized in the android_freezer_events table in the PerfettoSQL standard library.
中文翻译版
概述
缓存应用冻结器用于停止缓存进程的执行。正如文档所述，它"减少了那些试图在缓存状态下继续运行的不良应用所占用的资源"。该机制将应用保留在 RAM 中，但使其完全脱离 CPU。Android 不会立即杀死当前不需要但将来可能需要的应用，而是冻结该应用进程，以便在再次需要该应用时避免冷启动。
冻结通过将进程迁移到冻结的 cgroup 来实现，从而消除缓存应用的活跃 CPU 消耗和空闲 CPU 消耗。该功能可以通过系统配置标志或开发者选项来启用。
从 Android 14（API 级别 34）开始，行为变得更加健壮，引入了两条具体规则：
- 缓存的应用进程在进入缓存状态 10 秒后 被冻结。
- 冻结的进程在任何生命周期事件发生时 立即解冻 — 例如接收 Intent、启动 JobService，或用户恢复 Activity。
文档指出了两个关键组件：ActivityManagerService 负责管理所有应用进程的生命周期决策，而 CachedAppOptimizer 是实际执行冻结操作的组件。
当应用进程被冻结时，所有线程都被挂起，在解冻之前无法执行任何 CPU 工作。这意味着应用无法执行垃圾回收（GC），也无法响应内存裁剪事件（ComponentCallbacks2.onTrimMemory(int)）。为了应对这一问题，Android 14 引入了以下几项适配措施：
- 拥有可见 Activity 的应用在进入后台时会立即收到
TRIM_MEMORY_UI_HIDDEN 通知。没有 UI 的应用（例如运行前台服务的应用）可能会收到 TRIM_MEMORY_BACKGROUND。其他裁剪事件不会下发，因为应该接收这些事件的应用此时预计已被冻结。 - 在应用进入缓存状态后不久，系统可能会要求运行时执行一次 GC，为可能的冻结做好准备。
- 当应用进程被冻结时，可能会进行额外的内存压缩，包括将脏页写入后备存储以及将匿名页交换到 ZRAM。
- 如果属于某个应用的所有进程都被冻结，系统会终止该应用持有的所有活跃 TCP 套接字。这样可以阻止服务端发送 TCP keepalive 探测包，避免唤醒设备调制解调器。
缓存应用进程在其进程状态从"缓存"提升到更高重要性级别时解冻。为了减少 Android 14+ 中的解冻事件，系统会在应用处于缓存状态时排队处理上下文注册的广播。这些是通过 Context.registerReceiver 动态注册的接收器。排队的广播仅在应用解冻后才投递。相比之下，清单声明的广播（在 AndroidManifest.xml 中通过 <receiver> 静态声明的接收器）不会被排队 — 系统会立即解冻缓存应用以投递它们。
系统健康影响
当缓存进程的数量超过 MAX_CACHED_PROCESSES 时，Android 会终止最近最少使用的缓存应用进程。在运行 Android 14+ 的受支持设备上，此常量被大幅提高，使设备能够在 RAM 中保留更多的缓存进程。
文档报告称，通过在 RAM 中保留更多缓存应用，**冷启动次数最多减少了 30%**，减少幅度与设备总 RAM 成正比。与此同时，缓存应用的 CPU 使用率被降至最低，从而显著节省电池电量。
冻结豁免
在某些情况下，应用进程可能进入缓存状态但仍保持未冻结。这些是实现细节，可能会在未来的 Android 版本中发生变化：
- 文件锁：持有阻塞非缓存进程的文件锁的缓存进程不会被冻结。
BIND_WAIVE_PRIORITY 绑定：使用 Context.BIND_WAIVE_PRIORITY 创建了传入绑定的应用进程，即使变为缓存状态也可能保持未冻结，直到所有连接的客户端进程也变为缓存状态。此豁免支持多进程应用，例如使用 Custom Tabs 的 Web 浏览器。
实现应用冻结器
该功能依赖于内核 cgroup v2 冻结器。搭载兼容内核的设备可以开启此功能。
要启用，可以打开开发者选项 暂停执行已缓存的应用，或设置设备配置标志：
adb shell device_config put activity_manager_native_boot use_freezer true && adb reboot
要禁用，将标志设为 false 或关闭开发者选项：
adb shell device_config put activity_manager_native_boot use_freezer false && adb reboot
此开关可以通过软件发布或更新中的设备配置来更改。
要覆盖 MAX_CACHED_PROCESSES（例如，将其设置为 1024 用于测试）：
adb shell device_config put activity_manager max_cached_processes 1024
adb shell device_config set_sync_disabled_for_tests persistent
要还原覆盖：
adb shell device_config delete activity_manager max_cached_processes
adb shell device_config set_sync_disabled_for_tests none
冻结器 不提供公开 API，也没有参考实现客户端。但它使用了隐藏的系统 API：setProcessFrozen 用于冻结单个进程，enableFreezer 用于全局启用或禁用冻结功能。
处理自定义功能
应用进程不应在缓存状态下执行任何工作。然而，某些应用可能拥有由预期在缓存期间运行的进程支持的自定义功能。当冻结器在此类应用的设备上启用时，这些缓存进程会被冻结，从而可能破坏这些自定义功能。
解决办法是：在任何工作执行之前，将进程状态更改为非缓存状态。活跃状态，如绑定前台服务（BFGS）或前台状态，将使应用保持活跃。
常见故障模式
不当的 IPC 或任务调度可能导致进程被终止或出现意外行为。
对冻结进程的同步 Binder 事务
当客户端向冻结的服务端进程发送同步 binder 事务时，系统会立即终止服务端进程。这是为了防止客户端线程无限期阻塞。随后客户端会收到 RemoteException，并且所有已注册的监听器会被触发（参见 IBinder.linkToDeath）。
根本原因：这通常是一个客户端 bug。当客户端绑定到服务时，服务端进程被绑定到客户端，无法在客户端之前变为缓存状态（参见 Context.bindService）。然而，一旦客户端调用 Context.unbindService，服务端进程就可能变为缓存状态并被冻结。如果客户端在取消绑定后继续使用已缓存的 IBinder 引用，就有可能与被冻结的进程通信。
修复方法：客户端应在调用 Context.unbindService 后立即丢弃 IBinder 引用。
异步 Binder 事务缓冲区溢出
当服务端进程在冻结状态下收到异步（oneway）binder 事务时，这些事务会在每个进程的缓冲区中累积。如果在进程冻结期间积累了过多事务，缓冲区会溢出，系统将终止服务端进程。
预防方法：避免向可能被缓存或冻结的进程发送过多的异步 binder 事务。
解冻后计划任务的重复执行
如果应用运行重复性任务（通过 ScheduledThreadPoolExecutor.scheduleAtFixedRate 或 Timer.scheduleAtFixedRate），这些任务在进程被冻结期间会被挂起。当进程解冻时，所有累积的未执行任务可能会快速连续执行，彼此之间几乎没有延迟。
为避免这种突发执行，应使用 scheduleWithFixedDelay 而不是 scheduleAtFixedRate 来安排后台任务。或者，使用 WorkManager。
测试与故障排查
提供了以下几种诊断工具和命令：
Activity Manager 命令
使用 adb shell am 手动冻结、解冻或压缩进程：
adb shell am freeze <process> # 冻结进程
adb shell am unfreeze <process> # 解冻进程
adb shell am compact full <process> # 完全内存压缩
Logcat 检查
查看进程每次迁移进/出冻结器时的冻结和解冻条目：
adb logcat | grep -i "\(freezing\|froze\)"
解冻原因日志输出 UnfreezeReason 协议缓冲区枚举中的枚举值。
Dumpsys 检查
查看冻结进程列表：
adb shell dumpsys activity | grep -A 20 "Apps frozen:"
同时检查文件 /sys/fs/cgroup/uid_0/cgroup.freeze 是否存在。
ApplicationExitInfo
要查询之前进程退出的原因，使用 ActivityManager.getHistoricalProcessExitReasons。如果进程因冻结器相关问题被终止（例如在冻结状态下收到同步 binder 事务），退出原因为 ApplicationExitInfo.REASON_FREEZER。
Perfetto 追踪
冻结器相关事件显示在 system_server 进程下名为 Freezer 的轨道上：
Freeze 和 Unfreeze 切片展示状态转换。updateAppFreezeStateLSP 事件展示系统服务器重新检查进程属性以决定冻结/解冻的时刻。
可以在 Perfetto UI 中查看，或通过 PerfettoSQL 查询：
INCLUDE PERFETTO MODULE slices.with_context;
SELECT *
FROM process_slice
WHERE process_name = "system_server"
AND track_name = "Freezer"
AND (nameLIKE"Freeze %"ORnameLIKE"Unfreeze %");
冻结器事件也在 PerfettoSQL 标准库的 android_freezer_events 表中做了汇总。
参考： https://source.android.google.cn/docs/core/perf/cached-apps-freezer
10个月宝宝每天需要喝多少奶粉？
