Hey there, I’ve run into this exact issue with custom Android skins like MIUI, ColorOS, and FuntouchOS countless times—they’re notoriously aggressive with background task restrictions that break standard Android component behavior. Let’s break down why your current setup isn’t working and what you can do to fix it:

1. First and Foremost: Get the User to Grant Critical Permissions #

Custom ROMs lock down two key permissions by default, and without them, no background mechanism will work reliably:

• Auto-Start Permission: These OSes block third-party apps from launching themselves automatically. You’ll need to guide users to enable this via device-specific paths:
  • MIUI: Settings → Apps → Manage Apps → [Your App] → Auto-start
  • ColorOS (OPPO): Settings → Apps → App Management → [Your App] → Auto-launch
  • FuntouchOS (VIVO): Settings → Apps & Permissions → Permission Management → Auto-start
• Battery Optimization Whitelist: Your app is likely being put into deep sleep even if it tries to restart. You can prompt users to exclude your app via code, and also provide manual steps:

  // Request ignore battery optimization
  val intent = Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS)
  intent.data = Uri.parse("package:" + context.packageName)
  startActivity(intent)
  

  Manual paths for reference:
  • MIUI: Settings → Battery & Performance → Battery Saver → App Battery Saver → [Your App] → No restrictions
  • OPPO: Settings → Battery → App Battery Management → [Your App] → Allow background activity
  • VIVO: Settings → Battery → High Power Consumption Apps → Add [Your App]

2. Ditch Sticky Service for WorkManager #

Starting from Android 8.0, background services are heavily restricted, and custom ROMs enforce this even more strictly. WorkManager is Google’s recommended solution for deferred/periodic tasks, and it’s designed to work around these restrictions:
Here’s how to set up a 1-minute periodic task:

// Define your Worker class to handle the wake-up logic
class AlarmWorker(context: Context, params: WorkerParameters) : Worker(context, params) {
    override fun doWork(): Result {
        // Execute your app wake-up logic here (e.g., trigger a broadcast or app function)
        return Result.success()
    }
}

// Schedule the periodic task
val constraints = Constraints.Builder()
    .setRequiredNetworkType(NetworkType.NOT_REQUIRED) // Adjust if your task needs network
    .build()

val periodicRequest = PeriodicWorkRequestBuilder<AlarmWorker>(1, TimeUnit.MINUTES)
    .setConstraints(constraints)
    .build()

WorkManager.getInstance(context).enqueueUniquePeriodicWork(
    "MinuteAlarm",
    ExistingPeriodicWorkPolicy.REPLACE,
    periodicRequest
)

WorkManager will handle rescheduling automatically even if the app is killed or the device reboots (as long as auto-start permission is enabled).

3. Use a Foreground Service If You Must Stick with Services #

If your use case requires a persistent service, convert it to a Foreground Service—custom ROMs are far less likely to kill services that show a persistent notification:

class AlarmService : Service() {
    override fun onCreate() {
        super.onCreate()
        // Create notification channel for Android 8.0+
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
            val channel = NotificationChannel(
                "alarm_channel",
                "Alarm Service",
                NotificationManager.IMPORTANCE_LOW
            )
            val manager = getSystemService(NotificationManager::class.java)
            manager.createNotificationChannel(channel)
        }
        // Start foreground with a minimal, non-intrusive notification
        val notification = NotificationCompat.Builder(this, "alarm_channel")
            .setContentTitle("App is active")
            .setContentText("Maintaining your alarm schedule")
            .setSmallIcon(R.drawable.ic_notification)
            .build()
        startForeground(1, notification)
    }

    // Rest of your service logic (e.g., alarm triggering) goes here...
}

Don’t forget to declare the foreground service permission in your AndroidManifest.xml:

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

4. Enhance Your Broadcast Receiver Setup #

Your current broadcast receiver might not be receiving intents after the app is killed. Try these tweaks:

• Register for BOOT_COMPLETED and PACKAGE_REPLACED broadcasts to reinitialize your alarm/task when the device boots or app updates. For Android 12+, you’ll need to request the RECEIVE_BOOT_COMPLETED permission and use a manifest-registered receiver.
• Avoid relying solely on TaskRemoved—some ROMs don’t send this intent reliably. Instead, use WorkManager’s built-in retry mechanisms for more consistency.

Why Your Original Setup Failed #

Custom ROMs like MIUI and ColorOS have their own proprietary background process killers that bypass Android’s standard sticky service behavior. When the app is killed, these systems often prevent broadcast receivers from firing, and even if they do, starting a service directly might be blocked entirely.

Final Notes #

Even with all these steps, keep in mind that some users might still have issues if they’ve enabled aggressive battery saving modes. It’s a good idea to add a setup screen in your app that guides users through enabling these permissions with clear, device-specific instructions.

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