Programming Tutorials

  Engineers working in Android VoIP development or building custom dialers inevitably encounter a severe fragmentation issue on Xiaomi, Redmi, and Poco devices. You declare the standard   SYSTEM_ALERT_WINDOW   permission, request it via standard APIs, and verify it using   Settings.canDrawOverlays(context) . The API returns   true , yet when a VoIP call comes in while the app is backgrounded, the custom call screen fails to appear. This silent failure occurs because MIUI implements a secondary, hidden permission overlay strictly for background execution: the "Display pop-up windows while running in the background" permission. This article details the root cause of this undocumented restriction and provides a production-ready Java implementation to detect and resolve it. The Root Cause: MIUI's AppOps Customization In stock Android, the system alert window acts as a global capability flag. If the user grants the Android overlay permission via  ACTION_MANAGE_O...

  You have built a robust Android background service. It runs perfectly on Google Pixel devices and the Android Emulator. However, within minutes of deploying it to a Xiaomi device running MIUI, the process is abruptly terminated. Alarms fail to fire, WorkManager jobs are ignored, and foreground services disappear. This is a known, pervasive issue in mobile app development. While standard Android battery optimization relies on predictable states like Doze mode and App Standby Buckets, OEMs like Xiaomi (MIUI), Huawei, and Samsung implement custom, aggressive task killers. This guide details the technical root cause of MIUI's process management and provides a complete, modern Kotlin solution to prevent your WorkManager and Foreground Services from being killed. The Root Cause: AOSP vs. MIUI PowerKeeper To solve this, you must understand how MIUI diverges from the Android Open Source Project (AOSP). In standard AOSP,  WorkManager  relies on the  JobScheduler  API. ...