Does an Android notification channel created by expo-notifications persist after an app reinstall or OS upgrade?

Short answer

No to the first, yes to the second, and no to the third — with one important caveat on each.

• Reinstall: uninstalling removes all app data, including every notification channel the app created. A reinstall is a clean slate; the system does not restore the old channel settings or the user's manual importance changes.
• OS upgrade: channels are stored by the system against your package name and survive an Android version upgrade as long as the app stays installed and its data isn't cleared. You do not need to re-assert them, though re-creating is harmless.
• Detecting user overrides: there is no supported API in expo-notifications (or a practical one in the underlying Android SDK) that tells you a user lowered a channel's importance. You can read the channel's current importance, but you cannot subscribe to changes or distinguish "user changed it" from "created that way."

What this means for your channel migration

Because a reinstall wipes channels, your migration to new channel IDs is actually simpler than it looks: new installs and reinstalls get the new IDs immediately. The only cohort that matters is existing users who upgrade the app in place — they keep the old channel (with any user-modified importance) until you ship the new ID and they get a build that creates it.

Calling setNotificationChannelAsync on every launch is safe and idempotent: Android ignores updates to an existing channel's importance, sound, and vibration, so re-asserting creation costs nothing and guarantees the channel exists after edge cases like data clears. It will not, however, undo a user's manual downgrade — that immutability is by design.

Working around the "user lowered importance" blind spot

You can read the current state of a channel at runtime. On the native side this is NotificationManager.getNotificationChannel(id).getImportance(); in Expo you can inspect channels via getNotificationChannelsAsync() (Android only, SDK 51+ — verify against your SDK version's API reference, as this surface has changed between releases). A pragmatic pattern:

1. On launch, read the channel's importance. If it is lower than you created it with, treat that as a user signal.
2. Stop routing notifications to that channel from your backend (track a per-device flag), or show an in-app prompt deep-linking to the channel settings via Linking.openSettings() / the channel settings intent rather than silently continuing to send.
3. Never try to "fix" it by recreating the channel — you can't, and deleting/recreating a channel the user modified is blocked by the system precisely to prevent that.

Verify before shipping

These behaviors are well-established Android platform semantics, but confirm them on your target devices and Expo SDK version:

adb shell dumpsys notification | grep -A 10 your.package.name

Run this before and after an uninstall/reinstall (channels should be gone, then recreated only by your code), and after an OS update with the app installed (channels and importance should be intact). Also test the upgrade-in-place path from your current production build to the build with new channel IDs, confirming both old and new channels coexist and the old one stops receiving traffic.

One open detail worth checking on your side: if your backend keys notification routing by channel ID, confirm how it handles devices that haven't yet upgraded to the build containing the new IDs — that's the gap most channel migrations actually break on.