Android now grants the USE_FULL_SCREEN_INTENT permission by default only to apps built around calling and alarm functionality. Everything else — delivery apps, rideshare apps, any app that has historically used a full-screen notification to announce “your driver has arrived” or “your order is ready” — gets that notification quietly downgraded to a regular heads-up notification unless the user has explicitly granted the permission. The app still sends the same notification call; what the user sees is smaller, easier to dismiss without reading, and far less likely to interrupt whatever they’re doing at the moment it matters most.
This is a problem tracking has to catch because nothing about it looks like a bug. The notification API call succeeds, the event fires, and every existing “notification sent” metric looks unchanged. What breaks is downstream: open rates on time-sensitive notifications drop, and because the drop is gradual (new installs default to no permission, existing installs are unaffected until reinstalled or until Google Play revokes the permission outright), it’s easy to misread as a seasonal dip or a targeting problem rather than a platform-level notification downgrade hitting a specific segment of users.
Data Points to Track
- Full-screen intent permission status per device, checked via
NotificationManager#canUseFullScreenIntent(), so you know which users are actually seeing the full-screen version versus a downgraded one - Notification open rate segmented by permission status, comparing full-screen-eligible devices against downgraded ones for the same notification type
- Time from notification delivery to user action (opening the app, cancelling an order, acknowledging arrival), since a downgraded notification typically increases this delay even when it’s eventually seen
- Permission grant/deny outcome and timing, if you add an in-app prompt requesting the permission, tracked separately from other permission dialogs
- Install cohort (new vs. existing), since new installs default to the restricted state while existing installs may still carry the old permission until reinstalled
Setup Steps
- Call
canUseFullScreenIntent()at app launch and log the result as a user property, so every downstream notification metric can be segmented by it. - Confirm your app actually qualifies as a calling or alarm app under Android’s category rules, since misclassified apps lose the default grant with no separate warning.
- Build an in-app permission request flow for the “Manage full screen intents” setting if your notification use case depends on it, rather than assuming users will find it themselves in Special App Access.
- Tag time-sensitive notification events with intended delivery type (full-screen vs. standard) at send time, so you can compare intended versus actual delivery after the fact.
- Set an alert on open-rate deltas for your most time-sensitive notification category specifically, since a sitewide notification metric can mask a downgrade concentrated in one notification type.
Actionable Insights
Once permission status is tracked per device, the open-rate comparison tells you directly how much a full-screen downgrade costs in real terms — for most delivery and rideshare use cases, a heads-up notification that requires the user to actively check their phone converts to action meaningfully slower than one that takes over the screen. That gap is the business case for building a real in-app request flow for the permission rather than accepting the default, and tracking grant rate on that flow tells you whether users understand why you’re asking, or whether the request itself needs a clearer explanation before you write it off as a lost cause.
Related Resources
Need help tracking this in your app?
Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.
Talk to an expert