🚨 Full-Screen Intent (FSI) Notifications in Android 14 & 15: What Changed, Why It’s Breaking, and How to Fix It

Android’s Full-Screen Intent (FSI) notifications have been a cornerstone for apps requiring immediate user attention — think alarm clocks jolting you awake or phone calls demanding instant response. But if you’re an Android developer in 2024, you’ve likely discovered that your FSI notifications aren’t behaving as expected.

The harsh reality? Google has fundamentally changed how FSI works in Android 14 and 15, and many apps are breaking silently.

The Problem: Why Your FSI Notifications Stopped Working

Previously, implementing FSI was straightforward: build a notification with a fullScreenIntent, and it would reliably appear when the device was locked. Those days are over.

Starting with Android 14 (API 34) and continuing into Android 15, Google introduced strict limitations:

• FSI is now restricted to critical use cases only: calling and alarm apps
• No automatic permission: Apps outside these categories don’t get FSI permission by default
• Manual user consent required: Users must explicitly enable FSI in Settings
• Play Console declarations mandatory: Google requires developers to declare FSI use cases

What Reddit Developers Are Reporting

The Android development community has been vocal about these changes:

“It works only when the device is locked (with password/pin/finger). In all other cases it shows a regular notification.”

“When the user is using their phone, those are shown as notification in top app bar.”

Translation: FSI is now designed exclusively for lock-screen emergencies.

Who’s Affected by These Changes?

🔴 High-Impact Apps

• Alarm apps — Alarms may fail to wake the screen without proper Play Console declaration
• VoIP/calling apps — Incoming calls might show as banners instead of full-screen interfaces
• Emergency apps — Fire, SOS, or health monitoring apps could fail to alert users properly

🟡 Medium-Impact Apps

• Custom business apps — Logistics and field operation apps relying on urgent notifications
• Delivery apps — Driver arrival notifications will be downgraded to regular notifications
• Healthcare apps — Non-emergency but urgent medical reminders

Understanding how FSI behaves across different scenarios is crucial for building reliable notification systems:

[embed]

OEM-Specific Variations

Different manufacturers add their own layers of complexity:

• Samsung/Xiaomi: Often throttle background services aggressively
• Pixel devices: Follow Google’s implementation most closely
• Other OEMs: May have additional battery optimization restrictions

Technical Implementation: How to Handle FSI in Android 14+

1. Runtime Permission Check

Always verify FSI permission before attempting to use it:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.UPSIDE_DOWN_CAKE) {
    val notificationManager = context.getSystemService(NotificationManager::class.java)
    if (notificationManager.canUseFullScreenIntent()) {
        // Safe to send FSI
        sendFullScreenNotification()
    } else {
        // Permission not granted - implement fallback
        showPermissionPromptAndFallback()
    }
}

2. Redirecting Users to FSI Settings

Guide users to the correct settings page using the new Android 14+ intent:

fun navigateToFullScreenIntentSettings(context: Context) {
    try {
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.UPSIDE_DOWN_CAKE) {
            val intent = Intent(Settings.ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT).apply {
                data = Uri.fromParts("package", context.packageName, null)
                flags = Intent.FLAG_ACTIVITY_NEW_TASK
            }
            context.startActivity(intent)
        } else {
            // Fallback for older versions
            val intent = Intent(Settings.ACTION_APP_NOTIFICATION_SETTINGS).apply {
                putExtra(Settings.EXTRA_APP_PACKAGE, context.packageName)
                flags = Intent.FLAG_ACTIVITY_NEW_TASK
            }
            context.startActivity(intent)
        }
    } catch (e: Exception) {
        Log.e("FSI", "Failed to open settings", e)
    }
}

3. Complete Implementation Example

private fun handleFullScreenNotification() {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.UPSIDE_DOWN_CAKE) {
        val notificationManager = getSystemService(NotificationManager::class.java)

        if (!notificationManager.canUseFullScreenIntent()) {
            // Show user education dialog
            showFSIPermissionDialog()
            return
        }

        // Check for USE_FULL_SCREEN_INTENT permission
        if (ContextCompat.checkSelfPermission(this, 
            Manifest.permission.USE_FULL_SCREEN_INTENT) != PackageManager.PERMISSION_GRANTED) {

            ActivityCompat.requestPermissions(this,
                arrayOf(Manifest.permission.USE_FULL_SCREEN_INTENT), FSI_REQUEST_CODE)
            return
        }
    }

    // Proceed with FSI notification
    sendFullScreenNotification()
}

Comprehensive Strategies for Reliable FSI

Strategy 1: Play Console Declaration (Critical for Calling/Alarm Apps)

If your app genuinely falls into Google’s approved categories:

1. Declare your app as a calling or alarm app in the Play Console
2. Request USE_FULL_SCREEN_INTENT permission in your manifest
3. This ensures canUseFullScreenIntent() returns true after installation

Strategy 2: User Education and Onboarding

Create a seamless user experience when FSI permission is required:

private fun showFSIEducationDialog() {
    AlertDialog.Builder(this)
        .setTitle("Enable Important Notifications")
        .setMessage("To ensure you never miss critical alerts, please enable full-screen notifications for this app.")
        .setPositiveButton("Open Settings") { _, _ ->
            navigateToFullScreenIntentSettings(this)
        }
        .setNegativeButton("Later", null)
        .show()
}

Strategy 3: Robust Fallback Mechanisms

Heads-up Notifications

When FSI isn’t available, use high-priority heads-up notifications:

private fun createFallbackNotification(): Notification {
    return NotificationCompat.Builder(this, CHANNEL_ID)
        .setSmallIcon(R.drawable.ic_notification)
        .setContentTitle("Important Alert")
        .setContentText("Tap to view details")
        .setPriority(NotificationCompat.PRIORITY_HIGH)
        .setCategory(NotificationCompat.CATEGORY_CALL)
        .setFullScreenIntent(pendingIntent, false) // false = fallback to heads-up
        .setAutoCancel(true)
        .build()
}

Foreground Services

For persistent alerts like alarms or VoIP calls:

private fun startAlarmForegroundService() {
    val serviceIntent = Intent(this, AlarmForegroundService::class.java)
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
        startForegroundService(serviceIntent)
    } else {
        startService(serviceIntent)
    }
}

Strategy 4: System Alert Window (Last Resort)

For emergency use cases, consider overlay permissions as a final fallback:

private fun requestOverlayPermission() {
    if (!Settings.canDrawOverlays(this)) {
        val intent = Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION).apply {
            data = Uri.parse("package:$packageName")
        }
        startActivityForResult(intent, OVERLAY_PERMISSION_REQUEST_CODE)
    }
}

⚠️ Warning: Google Play Store is extremely strict about overlay permissions. Only use for genuine emergency scenarios and provide clear justification.

Strategy 5: OEM-Specific Optimizations

Handle manufacturer-specific battery optimization and background restrictions:

private fun requestBatteryOptimizationExemption() {
    val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
        if (!powerManager.isIgnoringBatteryOptimizations(packageName)) {
            val intent = Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS).apply {
                data = Uri.parse("package:$packageName")
            }
            startActivity(intent)
        }
    }
}

Testing Your FSI Implementation

Essential Test Scenarios

1. Device States:

• Test with screen locked and unlocked
• Verify behavior during active app usage
• Check response when device is in Do Not Disturb mode

2. Permission States:

• Test when FSI permission is granted
• Verify fallback when permission is denied
• Test the settings redirection flow

3. OEM Variations:

• Test on Pixel devices (Google’s reference implementation)
• Verify behavior on Samsung devices
• Check Xiaomi and other OEM-specific restrictions

Debug Utilities

private fun logFSIStatus() {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.UPSIDE_DOWN_CAKE) {
        val notificationManager = getSystemService(NotificationManager::class.java)
        Log.d("FSI_DEBUG", "Can use FSI: ${notificationManager.canUseFullScreenIntent()}")

        val hasPermission = ContextCompat.checkSelfPermission(this, 
            Manifest.permission.USE_FULL_SCREEN_INTENT) == PackageManager.PERMISSION_GRANTED
        Log.d("FSI_DEBUG", "Has USE_FULL_SCREEN_INTENT permission: $hasPermission")
    }
}

Best Practices and Recommendations

Do’s ✅

• Always check canUseFullScreenIntent() before sending FSI notifications
• Provide clear user education about why FSI permission is needed
• Implement robust fallback strategies for when FSI isn’t available
• Test thoroughly across different OEMs and Android versions
• Use FSI only for genuinely critical notifications

Don’ts ❌

• Don’t spam users with FSI for non-critical events (promotions, general updates)
• Don’t assume FSI will work without proper permission checks
• Don’t rely solely on FSI without implementing fallbacks
• Don’t abuse overlay permissions as a workaround
• Don’t ignore Play Console requirements for calling/alarm app declarations

Future-Proofing Your App

Google’s restrictions on FSI are likely to become even stricter in future Android versions. Here’s how to prepare:

1. Audit your FSI usage: Ensure every FSI notification truly requires immediate user attention
2. Invest in user onboarding: Create smooth flows for enabling FSI permissions
3. Strengthen fallback mechanisms: Build robust alternatives to FSI
4. Monitor user feedback: Track complaints about missed notifications
5. Stay updated: Follow Android developer announcements for future FSI changes

The Bottom Line

Full-Screen Intent notifications in Android 14 and 15 require a fundamentally different approach. There’s no universal hack to bypass Google’s restrictions — the platform has explicitly scoped FSI for alarms and calls only.

For apps that legitimately need FSI:

• Declare your use case properly in the Play Console
• Implement runtime permission checks
• Guide users through enabling FSI permissions
• Provide excellent fallback experiences

For apps outside the alarm/calling categories:

• Accept that FSI may not be available
• Focus on making heads-up notifications and other alternatives work brilliantly
• Don’t try to circumvent Google’s restrictions

The key to success lies in embracing these constraints rather than fighting them. By implementing proper permission checks, user education, and robust fallbacks, your app can continue delivering urgent notifications effectively — even in the post-FSI world.

Your users depend on your notifications. Make sure you’re ready for Android’s new reality.