[Bug report] Android change notifications fail for external_primary MediaStore volume

[JuoCode]

Version

3.10.0

Platforms

Android

Device Model

Android Emulator, Pixel 9 Pro (API 36); reproducible on any AVD

flutter info

[✓] Flutter (Channel stable, 3.44.4, on macOS 26.5.2 darwin-arm64)
    • Dart version 3.12.2
[✓] Android toolchain - develop for Android devices (Android SDK version 36.0.0)
    • Emulator version 36.2.12.0

How to reproduce?

1. Call PhotoManager.addChangeCallback(cb) and PhotoManager.startChangeNotify().
2. Drag an image from the host desktop into a running Android Emulator window (or, more generally, cause any insert that MediaStore announces on the external_primary volume URI only).
3. The image is indexed by MediaStore and appears in getAssetPathList results after a manual refresh — but cb is never invoked.

Root cause

PhotoManagerNotifyChannel.kt registers its three ContentObservers only on the legacy external volume URIs:

private val imageUri = MediaStore.Images.Media.EXTERNAL_CONTENT_URI  // content://media/external/images/media
private val videoUri = MediaStore.Video.Media.EXTERNAL_CONTENT_URI
private val audioUri = MediaStore.Audio.Media.EXTERNAL_CONTENT_URI

Since API 29, MediaStore also exposes collections under the external_primary volume (MediaStore.VOLUME_EXTERNAL_PRIMARY, i.e. content://media/external_primary/...). Some insert paths — emulator drag-and-drop being the easiest to reproduce — post their change notification only on the external_primary URI. notifyForDescendants = true does not help, because content://media/external_primary/images/media is a sibling of content://media/external/images/media, not a descendant.

Note this is distinct from #1117 / #1301 (limited-permission re-selection, fixed by #1357 via an explicit notify): here the observer registration itself never covers the volume, so no permission flow is involved.

Suggested fix

On API 29+, additionally register the same observers on the external_primary collections:

MediaStore.Images.Media.getContentUri(MediaStore.VOLUME_EXTERNAL_PRIMARY)
MediaStore.Video.Media.getContentUri(MediaStore.VOLUME_EXTERNAL_PRIMARY)
MediaStore.Audio.Media.getContentUri(MediaStore.VOLUME_EXTERNAL_PRIMARY)

Most real-device writes notify both volumes, so this will produce duplicate callbacks for a single insert; the plugin may want to debounce/coalesce internally (cf. #1219), or document that callers should. We currently work around the gap in our app with a host-side ContentObserver on external_primary bridged over an EventChannel, merged with the plugin callback behind a debounce — happy to turn the suggested fix into a PR if you're open to it.

Example code (optional)

PhotoManager.addChangeCallback((call) => debugPrint('change: $call'));
await PhotoManager.startChangeNotify();
// Drag a JPEG from the desktop into the emulator window: nothing is printed.

[fluttercandies-dev]

AI Summary: Android change notifications fail for the external_primary MediaStore volume (e.g., emulator drag-and-drop). Observers are only registered for the legacy external volume.

[AlexV525]

Thanks for the detailed report — the reproduction is solid, but the root cause turned out to be different from the diagnosis.

What's actually happening

I verified on API 34 and API 36 emulators (same setup as yours):

1. The notification does reach the plugin. MediaProvider notifies both the concrete volume and the merged external view for every row change (AOSP MediaProvider.acceptWithExpansion recurses into VOLUME_EXTERNAL). With log.tag.MediaProvider VERBOSE you can see Notifying content://media/external/images/media/<id> alongside the external_primary one, and the plugin's observer on the legacy tree fires.

2. The change is misclassified as delete. Files arriving via adb push / desktop drag-and-drop are owned by com.android.shell and stay is_pending=1 forever, so they're invisible to your app's queries. The plugin classifies events by re-querying the row; the query returns nothing, and the code concludes "row gone ⇒ delete". So cb is invoked, but with type: delete — which most callers (reasonably) ignore for a fresh insert, making it look like the callback never fired.

Why the suggested fix would backfire

Since both external_primary and the merged external view are notified for regular writes, registering observers on external_primary too would deliver two callbacks per change on real devices.

The fix

API 30+ MediaProvider tags row notifications with NOTIFY_INSERT/NOTIFY_UPDATE/NOTIFY_DELETE flags (verified values: insert=5, update=9, delete=17). #1444 uses the flag as the authoritative change type instead of re-querying, which fixes the misclassification and also removes the "within 30s ⇒ insert" heuristic inaccuracy. API < 30 keeps the existing inference.

With #1444, your drag-and-drop repro yields type: insert on API 36.