fix: read EXIF orientation directly for plain file paths - #156
Draft
dcalhoun wants to merge 1 commit into
Draft
Conversation
getImageOrientation prefixed non-content paths with "content://media"
and queried the MediaStore content provider first, falling back to EXIF
when that failed. For a plain filesystem path pointing at an existing
file (e.g. an app cache file), that constructed Uri is never resolvable
and the query always fails — on some devices by throwing
IllegalArgumentException ("Volume data not found"), which was logged
as an error with a stack trace on every call.
Such files carry their orientation only in EXIF, so read it directly
and skip the doomed provider query. MediaStore-style paths (which do
not exist on the filesystem) keep the previous behavior.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
7 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
ImageUtils.getImageOrientationprefixes any non-content://path withcontent://mediaand queries the MediaStore content provider first, only falling back to reading EXIF when that query returns nothing.For a plain filesystem path pointing at an existing file (e.g. an app cache file), that constructed
Uriis never resolvable through MediaStore, so the query always fails. On some devices it fails by throwingIllegalArgumentException: Volume data not found, which is caught but logged as an error with a full stack trace on every call:The orientation was still resolved correctly (via the EXIF fallback), so this was benign but noisy — and increasingly common now that hosts optimize images staged in their own cache directories (e.g. GutenbergKit's native media upload processing).
Fix
When the path is a plain filesystem path that points at an existing file, read EXIF orientation directly and skip the doomed provider query. EXIF is the only orientation source such a file has, so this is behavior-preserving. MediaStore-style paths (which don't exist on the filesystem) keep the previous query-then-EXIF-fallback behavior.
Testing
Verified in a host app (wordpress-mobile/WordPress-Android#23142) that optimizes an image staged in its cache dir: before this change the error + stack trace logged on every upload; after, it's gone and orientation is still applied correctly.
Co-authored with Claude.