Hi, I made a snack where I set one channel to high and another to max. However, when I run the project, they show up in my phone as max for both of them.
I expect channel a to be Urgent and channel b to be High. I read the docs and it said that the default settings can only be set when the channel is initially created. I verified that I had never run anything else on this device before, so I know that I specified the desired settings of Urgent ('max') and High ('high') when they were first created as is necessary. And I never changed them in the Android settings GUI.
If the Expo app unconditionally sets channel priority to Urgent, how can I test that my app will correctly set the priority to high instead of max when I publish a standalone app? Or am I somehow doing something wrong (i.e., is the behavior of priority: 'high'supposed to be the same as priority: 'max' for some reason I donât know)?
Iâm using a OnePlus5 with latest OxygenOS. EDIT: This is a OnePlus5 running OxygenOS-5.1.5 (Android-8.1.0 Android Security Patch level 2018-08-01). Based on the OnePlus forums, I suspect that this might be an OxygenOS bug. Please help me confirm by letting me know if if the snack produces the behavior I see for you if you and include your phone model and software versions. Particularly, if other OnePlus5 users have the same issue and non-OnePlus5 users donât have the issue, thatâd be helpful to know.
EDIT: A friend with OxygenOS-5.1.11 on a OnePlus6 also repros this. We need input from someone with a different phone brand still
This also reproduces on Galaxy S8 and Android Emulator.
Is the channel priority setting actually supposed to make a difference between high and max on Android? Is maybe Android setting it to Urgent (max) for both when I want to be non-instrusive to users and set to High (high) by default instead?
Hi @binki - this is just a weird quirk of the Android OS. While they provide constants for âhighâ and âmaxâ priority (along with âlowâ, âminâ, and âdefaultâ), they make no guarantees about UI behavior or labels that these map to. Expo simply maps these straight through to JS (Iâve just verified there are no mis-mappings there) so what youâre seeing is that the OS youâre running doesnât differentiate between âhighâ and âmaxâ priority in the UI. ÂŻ\(ă)/ÂŻ
FWIW, the âExperience notificationsâ channel is actually created with default priority, so you could try creating your channel without the priority field if you want the âHighâ text in the UI on that particular device.
Thanks for the reply! This really helped me get past being stuck.
I thought that my only options were low, min, high, max, but apparently putting any other string or omitting it entirely gets IMPORTANCE_DEFAULT which happens to map to the right thing on my device. Looks like that is what I want.
Hi @binki - glad that helped! I wish the Android API were less vague too we could change our mapping to match the current UI text instead, but then if Android decides to change its UI in the future our mapping would no longer make any sense. (It may already be different depending on the device/manufacturer, since there are multiple different versions of the Android OS.) However, Iâll update the docs to be more clear about this.
@esamelson Keeping the API mapping as close to the Android API as possible is good. The less magical it is, the more itâs like weâre writing native code and itâs a lot less fragile.
Looking forward to the documentation updates. Would be helpful if there were screenshots and a description of what users on most 8+ phones can expect to see for each of the priority/importance levels.
If I could change anything about the API itself, would be to recognize the string value 'default' and saying that that is the value that will be used if the priority key is omitted. Then the progression of 'min', 'low', 'default', 'high', 'max' would be fully represented in the API in a less confusing way IMO. Also, it is true that the Android API seems to be calling this âimportanceâ rather than âpriorityâ now. Maybe youâre staying with priority for consistence within Expo itself. Anyway, itâs too late for you to change the API at this point, so I just have to use it as it is now ;-).