AlarmManager与JobScheduler适配全Android版本？闹钟功能选型咨询

Hey there! Let's walk through the best way to build your alarm solution that meets all your requirements, while keeping compatibility across Android 4.0 and above. I know dealing with different API versions can feel overwhelming, but we can wrap this up with a clean, maintainable approach.

Your needs (precision, multi-alarm support, wake-up capability) map perfectly to a combination of AlarmManager + BroadcastReceiver + manual WakeLock management. Here's how to make it work across all your target versions:

1. AlarmManager: The Foundation for Precision #

AlarmManager is the only system-level component that guarantees your alarms will trigger even when your app isn't running. The key is using version-specific methods to maintain second-level precision:

• Android 4.0-4.3 (API 14-18): Use AlarmManager.set(AlarmManager.RTC_WAKEUP, triggerTime, pendingIntent) — before API 19, the system didn't batch alarms, so this was fully precise.
• Android 4.4-6.0 (API 19-22): Switch to AlarmManager.setExact(AlarmManager.RTC_WAKEUP, triggerTime, pendingIntent). API 19 introduced alarm batching for battery savings, so set() no longer guarantees precision.
• Android 6.0+ (API 23+): Use AlarmManager.setExactAndAllowWhileIdle(AlarmManager.RTC_WAKEUP, triggerTime, pendingIntent). This bypasses Doze mode and app standby, ensuring your alarm wakes the device even when it's in deep sleep.
• Android 12+ (API 31+): You'll need to request the SCHEDULE_EXACT_ALARM permission (dynamic request, as it's a dangerous permission) to use exact alarm methods.

Wrap these into a helper class to avoid repeating version checks everywhere:

public class AlarmScheduler {
    public static void scheduleExactAlarm(Context context, long triggerTimeMs, int alarmId, PendingIntent pendingIntent) {
        AlarmManager alarmManager = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);
        if (alarmManager == null) return;

        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
            alarmManager.setExactAndAllowWhileIdle(AlarmManager.RTC_WAKEUP, triggerTimeMs, pendingIntent);
        } else if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
            alarmManager.setExact(AlarmManager.RTC_WAKEUP, triggerTimeMs, pendingIntent);
        } else {
            alarmManager.set(AlarmManager.RTC_WAKEUP, triggerTimeMs, pendingIntent);
        }
    }
}

2. Multi-Alarm Support #

To create multiple independent alarms, just use unique requestCode values when creating PendingIntent instances. This ensures AlarmManager treats each alarm as a separate entry instead of overwriting existing ones:

// Create first alarm
Intent alarmIntent1 = new Intent(context, AlarmTriggerReceiver.class);
PendingIntent pendingIntent1 = PendingIntent.getBroadcast(
    context,
    1001, // Unique request code
    alarmIntent1,
    PendingIntent.FLAG_UPDATE_CURRENT | PendingIntent.FLAG_IMMUTABLE
);
AlarmScheduler.scheduleExactAlarm(context, triggerTime1, 1001, pendingIntent1);

// Create second alarm
Intent alarmIntent2 = new Intent(context, AlarmTriggerReceiver.class);
PendingIntent pendingIntent2 = PendingIntent.getBroadcast(
    context,
    1002, // Different request code
    alarmIntent2,
    PendingIntent.FLAG_UPDATE_CURRENT | PendingIntent.FLAG_IMMUTABLE
);
AlarmScheduler.scheduleExactAlarm(context, triggerTime2, 1002, pendingIntent2);

3. Wake Up & Keep Device Awake #

Forget WakefulBroadcastReceiver — it's deprecated as of API 26. Instead, manage a WakeLock manually to keep the CPU running until your task is complete:

1. Add the WAKE_LOCK permission to your AndroidManifest.xml:

<uses-permission android:name="android.permission.WAKE_LOCK" />

2. In your BroadcastReceiver, acquire the lock and start a service/activity to handle the task:

public class AlarmTriggerReceiver extends BroadcastReceiver {
    private static final String WAKE_LOCK_TAG = "AlarmWakeLock";
    private PowerManager.WakeLock wakeLock;

    @Override
    public void onReceive(Context context, Intent intent) {
        // Acquire wake lock to prevent CPU from sleeping mid-task
        PowerManager powerManager = (PowerManager) context.getSystemService(Context.POWER_SERVICE);
        wakeLock = powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, WAKE_LOCK_TAG);
        wakeLock.acquire(10 * 60 * 1000); // Timeout after 10 mins as a safety net

        // Start a foreground service (required for API 26+) to handle your task
        Intent taskIntent = new Intent(context, AlarmTaskService.class);
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
            context.startForegroundService(taskIntent);
        } else {
            context.startService(taskIntent);
        }
    }

    // Call this from your service/activity when the task is done
    public void releaseWakeLock() {
        if (wakeLock != null && wakeLock.isHeld()) {
            wakeLock.release();
        }
    }
}

3. In your AlarmTaskService, handle the user task, then release the wake lock when finished.

4. Handling Android 8.0+ Background Restrictions #

API 26 introduced strict background limits, so statically registered BroadcastReceivers won't receive alarms unless they're exempt. To work around this:

• Use PendingIntent.getForegroundService() instead of getBroadcast() if you're targeting API 31+
• Or, as shown above, start a Foreground Service from your BroadcastReceiver immediately — foreground services aren't subject to background restrictions.

• Persist Alarms: Save alarm details (trigger time, ID, task data) to SharedPreferences or a local database. Listen for the ACTION_BOOT_COMPLETED broadcast to re-schedule alarms after a device reboot.
• Permission Handling: For API 31+, request SCHEDULE_EXACT_ALARM dynamically. If the user denies it, you can fall back to approximate alarms, but this won't meet your precision requirement — so prompt the user to enable the permission in settings if needed.
• Test in Doze Mode: Use ADB commands (adb shell dumpsys deviceidle force-idle) to test if your alarm triggers correctly while the device is in deep sleep.

This approach keeps your codebase clean (no messy separate code paths for each version) and meets all your requirements. You'll only need version checks in a few helper methods, not scattered throughout your app.

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