App Standby — nó là gì, các cấp độ chờ và nguyên lý hoạt động

App Standby là gì

App Standby là một thành phần của hệ thống quản lý năng lượng Android, được giới thiệu trong Android 6.0 (API 23) và được thiết kế lại đáng kể trong Android 9 (API 28). Nhiệm vụ của nó là xác định ứng dụng nào người dùng ít sử dụng và hạn chế hoạt động nền của chúng: yêu cầu mạng, đồng bộ hóa, JobScheduler và AlarmManager. Không giống Doze, App Standby không phụ thuộc vào trạng thái màn hình hay chuyển động của thiết bị.

Hệ thống phân loại ứng dụng thành bốn bucket (cấp độ): Active, Working Set, Frequent và Rare. Mỗi cấp độ xác định mức độ hạn chế hoạt động nền. Việc chuyển đổi giữa các cấp độ diễn ra tự động dựa trên mô hình sử dụng ứng dụng: tần suất người dùng mở ứng dụng, nhận thông báo, tương tác với widget.

App Standby hoạt động cùng với Doze Mode nhưng không thay thế nó. Trong khi Doze hạn chế hoạt động nền của tất cả ứng dụng khi thiết bị không hoạt động, App Standby hạn chế các ứng dụng cụ thể không phụ thuộc vào trạng thái thiết bị. Một ứng dụng ở cấp độ Rare sẽ chịu hạn chế ngay cả khi điện thoại đang được sử dụng tích cực, nếu người dùng không mở nó trong vài ngày.

Bucket trong Android 9+

Bắt đầu từ Android 9 (API 28), Google đã giới thiệu App Standby Buckets — một phân loại chính thức với các giá trị số. Hệ thống sử dụng học máy để dự đoán lần khởi chạy tiếp theo của ứng dụng. Nếu mô hình dự đoán ứng dụng sẽ được mở trong vài giờ tới, nó nhận được bucket Active. Nếu dự đoán cho thấy ít sử dụng — nó được gán Rare.

Cách thức hoạt động của App Standby

App Standby phân tích một số yếu tố để xác định bucket: thời gian kể từ lần cuối người dùng mở ứng dụng, tần suất tương tác (số lần khởi chạy mỗi ngày/tuần), nhận thông báo FCM, sự hiện diện của widget hoạt động trên màn hình chính và đăng ký AlarmManager. Ứng dụng càng lâu không được sử dụng, bucket của nó càng thấp và các hạn chế càng nghiêm ngặt.

Dịch vụ hệ thống UsageStatsManager thu thập thống kê sử dụng ứng dụng và chuyển chúng đến StandbyController — một thành phần framework tính toán bucket cho mỗi ứng dụng. StandbyController cũng tính đến các sự kiện hệ thống: sau khi cập nhật ứng dụng, bucket của nó được đặt lại thành Active trong vài ngày để người dùng có thể đánh giá các tính năng mới.

Một tính năng quan trọng: App Standby không giết tiến trình ứng dụng mà chỉ hạn chế khả năng nền của nó. Ứng dụng tiếp tục hoạt động nếu người dùng đang tương tác với nó (bucket Active). Ngay khi người dùng thu nhỏ ứng dụng và không quay lại, hệ thống bắt đầu đếm thời gian không hoạt động và có thể hạ bucket xuống Working Set hoặc Frequent.

Ảnh hưởng của FCM đến bucket

Nhận được thông báo FCM ưu tiên cao có thể tạm thời nâng bucket của ứng dụng lên Active. Điều này cho ứng dụng cơ hội thực hiện một tác vụ (xử lý tin nhắn, đồng bộ dữ liệu) mà không bị hạn chế. Tuy nhiên, sau khi hoàn tất xử lý, bucket trở về giá trị ban đầu. Google khuyến nghị sử dụng cơ chế này để gửi các thông báo quan trọng, chứ không phải để giữ ứng dụng sống.

Cấp độ App Standby

App Standby sử dụng bốn cấp độ (bucket) để phân loại ứng dụng. Mỗi cấp độ xác định thời gian trễ cho các tác vụ nền: cấp độ càng thấp, thời gian trễ càng lâu. Hệ thống tự động di chuyển ứng dụng giữa các cấp độ dựa trên thống kê sử dụng được thu thập trong 7–14 ngày qua.

Active — Ứng dụng đang hoạt động

Active — ứng dụng mà người dùng đã tương tác gần đây (đã khởi chạy, nhận thông báo hoặc sử dụng widget). Trong bucket này không có hạn chế: JobScheduler chạy ngay lập tức, mạng khả dụng, AlarmManager kích hoạt chính xác. Ứng dụng ở trong Active cho đến khi người dùng ngừng tương tác với nó trong vài giờ.

Working Set và Frequent

Working Set — ứng dụng được sử dụng thường xuyên (vài lần mỗi tuần). Trễ tác vụ nền đến 2 giờ. Frequent — ứng dụng được sử dụng vài lần mỗi tháng. Trễ đến 4 giờ. Ở cả hai cấp độ, mạng chỉ khả dụng trong cửa sổ bảo trì và AlarmManager có thể bị hoãn. JobScheduler thực hiện các tác vụ trong cửa sổ gần nhất.

Rare — Ít được sử dụng

Rare — cấp độ nghiêm ngặt nhất, được gán cho các ứng dụng mà người dùng không mở trong hơn 30 ngày. Trễ tác vụ nền đạt 24 giờ. Mạng bị chặn hoàn toàn ngoài cửa sổ bảo trì, AlarmManager chỉ kích hoạt với cờ setAndAllowWhileIdle() với giới hạn 1 lần mỗi 9 phút. Thông báo FCM ưu tiên cao vẫn được gửi nhưng không thể nâng bucket.

Hạn chế trong App Standby

App Standby áp đặt các hạn chế đối với một số loại hoạt động nền. Không giống Doze, các hạn chế của App Standby được áp dụng không phụ thuộc vào trạng thái màn hình và sạc. Nhà phát triển phải thiết kế ứng dụng có tính đến các hạn chế này, đặc biệt nếu đối tượng mục tiêu sử dụng ứng dụng không thường xuyên.

JobScheduler và WorkManager

JobScheduler — API chính bị ảnh hưởng bởi App Standby. Tùy thuộc vào bucket, độ trễ thực thi tác vụ từ 2 đến 24 giờ. WorkManager, sử dụng JobScheduler bên trong (trên API 23+), cũng chịu các độ trễ này. Đối với các tác vụ quan trọng về thời gian, hãy sử dụng Expedited Work, khởi chạy Foreground Service bên trong và không bị ảnh hưởng bởi bucket.

Hạn chế mạng

Các ứng dụng trong bucket Working Set, Frequent và Rare không thể thực hiện các yêu cầu mạng tùy ý bất cứ lúc nào. Hệ thống chỉ cho phép truy cập mạng trong các cửa sổ bảo trì, được đồng bộ với Doze. Để gửi dữ liệu quan trọng, hãy sử dụng FCM ưu tiên cao kèm đồng bộ sau đó trong cửa sổ bảo trì.

AlarmManager

AlarmManager trong App Standby tuân theo các quy tắc giống như trong Doze: báo thức chính xác (setExact()) bị hoãn và setAndAllowWhileIdle() bị giới hạn 1 lần mỗi 9 phút. Đối với bucket Rare, độ trễ có thể đạt 24 giờ, khiến AlarmManager không phù hợp cho việc lên lịch chính xác các tác vụ trong các ứng dụng ít được sử dụng.

• JobScheduler — các tác vụ bị hoãn 2–24 giờ tùy theo bucket
• Mạng — chỉ truy cập trong cửa sổ bảo trì cho Working Set và thấp hơn
• AlarmManager — báo thức chính xác bị hoãn; setAndAllowWhileIdle — 1/9 phút
• SyncManager — đồng bộ tài khoản bị trì hoãn cho đến cửa sổ bảo trì
• Cập nhật Widget — tần suất cập nhật widget có thể bị giảm

Cách được miễn trừ

Có thể được miễn trừ khỏi App Standby bằng hai cách: thông qua cài đặt pin của người dùng (Whitelist thủ công) hoặc thông qua Intent hệ thống ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. Tuy nhiên, Google kiểm soát chặt chẽ việc tiếp cận các miễn trừ — các ứng dụng không có lý do chính đáng có nguy cơ bị từ chối trên Google Play.

Người dùng có thể tắt thủ công các hạn chế cho một ứng dụng cụ thể qua Cài đặt → Ứng dụng → [Ứng dụng] → Pin → Tối ưu hóa → Không tối ưu. Điều này loại bỏ hoàn toàn các hạn chế App Standby và Doze cho ứng dụng đã chọn. Nhà phát triển có thể hiển thị hướng dẫn hoặc hộp thoại hệ thống cho người dùng, nhưng không thể buộc thêm ứng dụng vào danh sách miễn trừ.

Foreground Service có thông báo tự động nhận được miễn trừ tạm thời khỏi App Standby. Khi dịch vụ đang chạy và hiển thị thông báo, ứng dụng được chuyển đến bucket Active bất kể cấp độ thực tế của nó. Sau khi dừng dịch vụ, bucket trở về giá trị ban đầu. Đây là cách đáng tin cậy nhất để đảm bảo công việc nền mà không cần yêu cầu miễn trừ hệ thống.

Khi nào yêu cầu miễn trừ

Yêu cầu Whitelist chỉ có ý nghĩa đối với các ứng dụng có chức năng nền quan trọng: định vị thời gian thực, theo dõi sức khỏe, cuộc gọi VoIP, bảo vệ thiết bị. Đối với hầu hết các ứng dụng, chỉ cần sử dụng Foreground Service hoặc WorkManager. Google Play có thể từ chối xuất bản nếu ứng dụng yêu cầu miễn trừ mà không có nhu cầu rõ ràng.

// Yêu cầu miễn trừ App Standby
val intent = Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS).apply {
    data = Uri.parse("package:\${applicationContext.packageName}")
}

// Kiểm tra trạng thái hiện tại
val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
val isIgnoring = powerManager.isIgnoringBatteryOptimizations(packageName)

Kiểm tra App Standby

Kiểm tra App Standby qua ADB cho phép bạn gán bất kỳ bucket nào cho ứng dụng và xác minh hành vi của nó. Điều này đặc biệt quan trọng đối với các ứng dụng dựa vào đồng bộ nền, thông báo hoặc cập nhật định kỳ. Kiểm tra phải được thực hiện trên thiết bị thật hoặc giả lập với Android 9+.

Để gán bucket, sử dụng lệnh adb shell am set-standby-bucket [package] [bucket], trong đó bucket có thể là: active, working_set, frequent hoặc rare. Để xem bucket hiện tại — adb shell am get-standby-bucket [package]. Hệ thống cũng cho phép mô phỏng sự không hoạt động kéo dài của ứng dụng qua lệnh adb shell dumpsys usagestats.

# Đặt bucket Rare cho ứng dụng
$ adb shell am set-standby-bucket com.example.app rare

# Xem bucket hiện tại
$ adb shell am get-standby-bucket com.example.app

# Đặt lại tất cả bucket về Active
$ adb shell dumpsys usagestats clear

# Xem tất cả bucket hệ thống
$ adb shell dumpsys usagestats

Những gì cần kiểm tra

Sau khi đặt bucket thành Rare, hãy kiểm tra: tác vụ WorkManager có thực thi trong vòng 24 giờ không, AlarmManager có kích hoạt không, thông báo FCM có được gửi không và Foreground Service có hoạt động không bị hạn chế không. WorkManager với chính sách Expedited Work sẽ thực thi ngay lập tức ngay cả trong bucket Rare vì nó sử dụng Foreground Service. Các tác vụ WorkManager thông thường sẽ bị hoãn theo bucket.

Thực hành tốt nhất

Phát triển một ứng dụng chống chịu được App Standby đòi hỏi một cách tiếp cận có ý thức đối với các tác vụ nền. Nguyên tắc chính: không cho rằng ứng dụng luôn ở trong bucket Active. Thiết kế công việc nền để nó thực hiện chính xác với các độ trễ đặc trưng của bucket Frequent và Rare.

Sử dụng WorkManager với Expedited Work

Expedited Work (WorkManager 2.7+) khởi chạy Foreground Service bên trong, cho phép tác vụ thực thi ngay lập tức bất kể bucket. Đây là lựa chọn tối ưu cho các tác vụ không thể trì hoãn: gửi tin nhắn, đồng bộ sau thanh toán, xử lý cuộc gọi đến. Các tác vụ WorkManager thông thường chạy trong cửa sổ bảo trì theo bucket.

FCM để kích hoạt lại

Sử dụng tin nhắn FCM ưu tiên cao để đánh thức ứng dụng khỏi App Standby. Khi ứng dụng nhận được tin nhắn như vậy, bucket của nó tạm thời được nâng lên Active, cho phép nó thực hiện các tác vụ cần thiết (đồng bộ, cập nhật dữ liệu). Sau khi hoàn tất xử lý, bucket trở về cấp độ ban đầu.

Tránh giữ bộ nhớ liên tục

Đừng cố gắng vượt qua App Standby bằng các dịch vụ nền liên tục, WakeLock hoặc tin nhắn FCM định kỳ. Google tích cực chống lại các thực hành này — ứng dụng có thể bị đánh dấu là tốn pin và bị hạn chế nghiêm ngặt hơn. Sử dụng WorkManager cho các tác vụ định kỳ và Foreground Service chỉ khi tác vụ thực sự hiển thị với người dùng.

• WorkManager — API ưa tiên; Expedited Work thực thi tác vụ không trễ
• FCM ưu tiên cao — tạm thời nâng bucket lên Active để xử lý tin nhắn
• Đừng vượt qua App Standby — điều này dẫn đến ứng dụng bị hệ thống chặn
• Foreground Service — tạm thời chuyển ứng dụng sang Active khi chạy
• Kiểm tra ứng dụng trong bucket Rare và Frequent qua ADB trước mỗi bản phát hành