How do I get FullScreenIntent accepted on playstore for an app that does not involve calling or alarms?

by

Summary

A developer attempted to publish an Android application using FullScreenIntent functionality without qualifying as a traditional calling or alarm app. Despite implementing the runtime permission flow correctly, the Play Store rejected the submission due to the presence of android.permission.USE_FULL_SCREEN_INTENT in the manifest. This postmortem examines the policy violations, misunderstood platform constraints, and proper architectural approaches for handling high-priority notifications.

Root Cause

The fundamental issue stems from a misalignment between technical capability and Play Store policy requirements:

  • Policy Restriction: Google Play Store policy explicitly limits FULL_SCREEN_INTENT to apps that are primary calling or alarm applications
  • Manifest Declaration Conflict: Including the permission in manifest automatically flags the app during review, regardless of runtime permission handling
  • Platform Evolution: Android 14+ changed default permissions, but this doesn’t override Play Store policy restrictions
  • Ecosystem Enforcement: The permission is greyed out when declared but the app doesn’t meet store requirements, creating an unusable permission state

Why This Happens in Real Systems

This scenario illustrates common enterprise development challenges:

  • Documentation vs Policy Gap: Technical documentation describes how to use features, but store policies dictate when they’re permissible
  • Assumption-Based Development: Developers assume runtime permission requests override manifest restrictions
  • Platform Constraint Misunderstanding: Android’s flexible permission model conflicts with centralized app store governance
  • Compliance Oversights: Teams often test functionality without comprehensive store policy validation

Key takeaway: Platform capabilities and distribution policies operate independently, requiring dual validation approaches.

Real-World Impact

Organizations face significant business consequences from such oversights:

  • Release Delays: Weeks lost to resubmission cycles and policy research
  • Resource Drain: Engineering time diverted from feature development to compliance fixes
  • User Experience Degradation: Critical notification features become unavailable or unreliable
  • Competitive Disadvantage: Delayed market entry affects user acquisition and retention
  • Technical Debt Accumulation: Quick fixes often create maintainable code challenges

Example or Code (if necessary and relevant)

// Example of compliant alternative using high-priority notifications
class NotificationHelper {
    fun createHighPriorityNotification(
        context: Context,
        channelId: String,
        title: String,
        message: String
    ): Notification {
        return NotificationCompat.Builder(context, channelId)
            .setContentTitle(title)
            .setContentText(message)
            .setPriority(NotificationCompat.PRIORITY_HIGH)
            .setCategory(NotificationCompat.CATEGORY_ALARM)
            .setVisibility(NotificationCompat.VISIBILITY_PUBLIC)
            .build()
    }
}

How Senior Engineers Fix It

Experienced engineers address this challenge through strategic planning:

  • Requirement Analysis: Evaluate whether FullScreenIntent is truly necessary or if standard high-priority notifications suffice
  • Policy Review: Consult Play Store documentation before implementing restricted features
  • Alternative Architecture: Implement notification channels with maximum priority and proper categories
  • Gradual Rollout Strategy: Use feature flags to conditionally enable restricted functionality
  • Documentation Alignment: Ensure technical implementation matches declared app purpose
  • Pre-submission Validation: Conduct policy compliance checks alongside functional testing

Best practice: Design notification systems with graceful degradation paths for different permission levels.

Why Juniors Miss It

Entry-level developers frequently overlook critical aspects:

  • Surface-Level Documentation Reading: Missing policy sections that contradict technical guides
  • Testing Environment Bias: Working on personal devices doesn’t reflect store review conditions
  • Permission Model Confusion: Misunderstanding the relationship between manifest declarations and runtime requests
  • Tool Over Function Focus: Concentrating on making code work rather than ensuring compliance
  • Inadequate Research: Not exploring alternative APIs that provide similar user experiences legally
  • Assumption Errors: Believing that because something is technically possible, it’s distribution-approved

Leave a Comment