Notifications, Sounds, Android 7.0, and Aggravation
You can put a custom ringtone on a
Notification, via methods like
NotificationCompat.Builder. This requires a
that causes problems on Android 7.0, as is reported by
a few people on
If you were using
Uri values, they no longer work on Android 7.0
targetSdkVersion is 24 or higher, as the sound
Uri is checked
for compliance with the ban on
However, if you try a
Uri from, say,
sound will not be played… because Android does not have read access to that
Here are some options for addressing this.
You can always grant permissions for content to other apps via
a method available on
Context. The challenge is in knowing who to
grant the permissions to.
What works on a Nexus 6P (Android 6.0… still…) and a Nexus 9 (Android 7.0) is:
grantUriPermission("com.android.systemui", sound, Intent.FLAG_GRANT_READ_URI_PERMISSION);
sound is the
Uri that you are using with
Whether this will hold up for all devices and all Android OS versions, I cannot say.
The Guillotine: No More User Files
android.resource as a scheme works fine for
Uri values for
Instead of allowing users to choose their own ringtone from a file,
you only allow them to choose one of several ringtones that you ship
as raw resources in your app. If this represents a loss of app
functionality, though, your users may be unimpressed.
The Axe: Use a Custom
FileProvider cannot be used when it is exported — it crashes on
startup. However, for this case, the only
Uri that will
work without other issues is one where the provider is
has no read access permissions (or happens to require some permission that
com.android.systemui or the equivalent happens to hold).
Eventually, I’ll add options for this to
part of some “read only” provider functionality.
But, you could roll your own provider for this.
The Chainsaw: Ban the Ban
The following code snippet blocks all
StrictMode checks related to
VM behavior (i.e., stuff other than main application thread behavior),
including the ban on
Alternatively, you could configure your own
VmPolicy with whatever
rules you want, just without calling
This allows you to use
Uri values anywhere. There are good
reasons why Google is banning the
Uri, and so trying to avoid
the ban may bite you in unfortunate body parts in the long term.
The Nuke: Use a Lower
This also removes the ban on
Uri values, along with all other
behavior that a
targetSdkVersion of 24+ opts into. Of note, this will
cause your app to display a “may not work with split-screen”
if the user enters split-screen multi-window mode.
The Real Solution: A Fix in Android
NotificationManager should be calling
for us, or there should be some other way for us to associate
FLAG_GRANT_READ_URI_PERMISSION with the
Uri that we use for custom
Stay tuned for further developments.
If you have found another workaround of note, let me know!
Nervous about how the newest version of Android affects your app? Consider subscribing, then asking questions in the office hours chats!