I'm trying to highlight the Override Do not Distrub channel setting upon opening the intent.

I have written the code according to this answer:

private const val EXTRA_FRAGMENT_ARG_KEY = ":settings:fragment_args_key"
private const val EXTRA_SHOW_FRAGMENT_ARGUMENTS = ":settings:show_fragment_args"
private const val EXTRA_BYPASS_DND = "bypass_dnd"

// ...

val intent = Intent(Settings.ACTION_CHANNEL_NOTIFICATION_SETTINGS).apply {
    putExtra(Settings.EXTRA_APP_PACKAGE, packageName)
    putExtra(Settings.EXTRA_CHANNEL_ID, channelId)
    putExtra(EXTRA_FRAGMENT_ARG_KEY, EXTRA_BYPASS_DND)
    putExtra(EXTRA_SHOW_FRAGMENT_ARGUMENTS,
        bundleOf(EXTRA_FRAGMENT_ARG_KEY to EXTRA_BYPASS_DND))

}
context.startActivity(intent)
Toast.makeText(context,
    "Grant the Override Do not Disturb permission", Toast.LENGTH_SHORT).show()

Unfortunately, the intent opens, but the setting is not highlighted. The bypass_dnd key is taken from the source code.

I'm trying to highlight the Override Do not Distrub channel setting upon opening the intent.

I have written the code according to this answer:

private const val EXTRA_FRAGMENT_ARG_KEY = ":settings:fragment_args_key"
private const val EXTRA_SHOW_FRAGMENT_ARGUMENTS = ":settings:show_fragment_args"
private const val EXTRA_BYPASS_DND = "bypass_dnd"

// ...

val intent = Intent(Settings.ACTION_CHANNEL_NOTIFICATION_SETTINGS).apply {
    putExtra(Settings.EXTRA_APP_PACKAGE, packageName)
    putExtra(Settings.EXTRA_CHANNEL_ID, channelId)
    putExtra(EXTRA_FRAGMENT_ARG_KEY, EXTRA_BYPASS_DND)
    putExtra(EXTRA_SHOW_FRAGMENT_ARGUMENTS,
        bundleOf(EXTRA_FRAGMENT_ARG_KEY to EXTRA_BYPASS_DND))

}
context.startActivity(intent)
Toast.makeText(context,
    "Grant the Override Do not Disturb permission", Toast.LENGTH_SHORT).show()

Unfortunately, the intent opens, but the setting is not highlighted. The bypass_dnd key is taken from the source code.

• android
• kotlin
• android-intent
• android-settings

Share Improve this question Follow asked Nov 16, 2024 at 1:18 BharelBharel 27.2k77 gold badges5050 silver badges9797 bronze badges 4

• 1 The Settings app is changed a lot by manufacturers. There is no guarantee that documented extras will be honored, let alone undocumented ones. – CommonsWare Commented Jan 5 at 13:03
• @CommonsWare thanks for the response. I'm working on a Pixel with pure Android, so I believe manufacturers should not matter (maybe for publishing but that's another story). You're saying this feature is completely undocumented and should seldom be used? – Bharel Commented Jan 5 at 21:24
• 1 "I'm working on a Pixel with pure Android" -- technically, the Pixel does not ship with "pure Android", though it is likely to be closer to the AOSP than just about anything else. "You're saying this feature is completely undocumented" -- yes. You will not find those const val values in the SDK, which is why you had to define them yourself. "and should seldom be used?" -- you are welcome to use it, just so long as you do not expect it to work reliably across device models. – CommonsWare Commented Jan 5 at 21:39
• @CommonsWare well, "no" or "impossible" is also an answer. You're welcome to add it and I'll accept :-) Thanks! – Bharel Commented Jan 9 at 9:15

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 1 +50

On the one hand, the Settings app is known to have a lot of undocumented Intent extras that can control its behavior, such as your three private const val ones at the top of your code listing.

However, undocumented extras are unreliable. That is especially true with the Settings app, where manufacturers mess with it all the time. Even documented actions and extras are unreliable, so much so that the documentation often calls this out. So while those extras show up in the AOSP source code, there is no guarantee that any given device will honor them. That includes Google's Pixel series — whereas the Nexus series tended to be very close to AOSP, the Pixels deviate, though less than with other major manufacturers.

So, you're welcome to include those extras. If they work, they work. From a testing standpoint, an Android SDK emulator is going to be closer to AOSP than is a Pixel, so you might try that. But, in the end, they are not going to work for everyone, so your UX and documentation needs to be able to cope with that.