能否使用JobScheduler替代BroadcastReceiver实现全部功能？

Alright, let's break down your problem and answer your key question: Yes, you can build your entire app using JobScheduler (or even better, WorkManager for broader compatibility) without relying on BroadcastReceivers—though you’ll need to adjust your logic to fit how job scheduling works, since it’s not a 1:1 replacement for BroadcastReceivers.

Let’s walk through how to map your original functionality to job scheduling, and address the API 27+ restrictions you’re hitting:

First, Why Your Original Setup Breaks on API 27+ #

As you noticed, Android 8.0 (API 27) introduced strict restrictions on statically registered BroadcastReceivers for most implicit broadcasts—including ACTION_POWER_CONNECTED and ACTION_POWER_DISCONNECTED. That’s why your first manifest-registered BR never works on API 27+. Additionally, background services are aggressively killed on API 26+ to save battery, which is why your Service dies when the app is closed, taking your dynamically registered ACTION_BATTERY_CHANGED BR with it.

Mapping Your Features to JobScheduler #

Your core needs are:

1. Detect when the device starts/stops charging
2. While charging, track battery status changes (even when the app is closed)

Here’s how to implement these with job scheduling:

1. Replace Charging Connect/Disconnect BRs with Job Triggers #

Instead of static BRs, use JobScheduler to trigger jobs based on charging state changes:

• For charging connect: Create a JobInfo with setRequiresCharging(true)—this job will be triggered when the device starts charging.
• For charging disconnect: Create another JobInfo with setRequiresCharging(false)—this triggers when charging stops.
• These jobs will run even if your app is closed, as long as the system deems it appropriate (battery/resource permitting).

2. Replace the Battery Status BR with Periodic Jobs #

ACTION_BATTERY_CHANGED is a sticky broadcast that can only be registered dynamically, but keeping a Service alive to hold that BR isn’t reliable on API 27+. Instead:

• Create a periodic job that only runs while the device is charging (use setRequiresCharging(true) in the job constraints).
• Each time this job runs, fetch the current battery status directly using BatteryManager (no BR needed!). You can get details like battery level, health, and charging status via Intent extras from BatteryManager.ACTION_BATTERY_CHANGED.
• Note: JobScheduler enforces a minimum interval of 15 minutes for periodic background jobs on API 26+. If you need more frequent updates, you’ll have to use a foreground Service (with a persistent notification) to bypass this restriction—but only if absolutely necessary, as it impacts battery life.

3. Handle Device Reboots #

JobScheduler jobs don’t survive device reboots, so you’ll need to reschedule them when the device starts up. You can use a dynamically registered BR for ACTION_BOOT_COMPLETED (this broadcast is still allowed for static registration on API 27+, but dynamic is safer for compatibility) to trigger a reschedule of your charging jobs.

Why WorkManager Is a Better Choice Than Raw JobScheduler #

While JobScheduler works, WorkManager (part of Jetpack) is a better pick because:

• It’s backward-compatible to API 14, automatically using JobScheduler, AlarmManager, or Firebase JobDispatcher based on the device’s OS version.
• It handles edge cases like device reboots and app updates automatically (you can enable setPersisted(true) for work requests).
• It has a simpler API for defining constraints (like charging state) and scheduling one-time/periodic tasks.

Quick WorkManager Example for Your Use Case #

1. Create a Worker to fetch battery status:

public class BatteryStatusWorker extends Worker {
    public BatteryStatusWorker(@NonNull Context context, @NonNull WorkerParameters params) {
        super(context, params);
    }

    @NonNull
    @Override
    public Result doWork() {
        // Fetch battery status
        Intent batteryIntent = getApplicationContext().registerReceiver(null, new IntentFilter(Intent.ACTION_BATTERY_CHANGED));
        int batteryLevel = batteryIntent.getIntExtra(BatteryManager.EXTRA_LEVEL, -1);
        int batteryScale = batteryIntent.getIntExtra(BatteryManager.EXTRA_SCALE, -1);
        float percentage = (batteryLevel / (float) batteryScale) * 100;

        // Do something with the battery status here

        return Result.success();
    }
}

2. Schedule the worker to run periodically while charging:

Constraints constraints = new Constraints.Builder()
        .setRequiresCharging(true)
        .build();

PeriodicWorkRequest batteryWorkRequest = new PeriodicWorkRequest.Builder(
        BatteryStatusWorker.class,
        15, TimeUnit.MINUTES) // Minimum allowed interval on API 26+
        .setConstraints(constraints)
        .setPersisted(true) // Survives reboots
        .build();

WorkManager.getInstance(context).enqueue(batteryWorkRequest);

3. When charging stops, cancel the periodic work:

WorkManager.getInstance(context).cancelUniqueWork("battery-tracking-work");

Why IntentService Wasn’t a Good Fit #

IntentService is designed for short-lived, one-time tasks—it stops itself as soon as it finishes processing an intent. It can’t stay alive to hold a dynamic BR, so it wouldn’t work for your need to track battery status continuously while charging.

Final Notes #

• Job scheduling isn’t as real-time as BroadcastReceivers: The system may delay job execution to save battery. If you need immediate updates (e.g., within seconds), you’ll need to use a foreground Service with a dynamic BR for ACTION_BATTERY_CHANGED—but be aware this will show a persistent notification to the user.
• Always test on API 27+ devices to ensure your jobs behave as expected, since background restrictions are most strict there.

内容的提问来源于stack exchange，提问作者Azzam Alsharafi