A Tale of Two ExifInterfaces
Many applications need access to EXIF headers from JPEG files, for everything from getting at geotag information to simply knowing how to rotate the image to display to the user.
Android has had an
ExifInterface class in the Android SDK since API
Level 5. While support for a few more tags have been added over the
years, the class is largely unchanged since it was introduced.
This includes one major limitation: it only works on files. You have to supply it with a filesystem path to the JPEG image to examine.
Back in 2009, this was not an unreasonable choice, given the programming
techniques of that Android era. Nowadays, it is just another hurdle for
developers to overcome, as many times your JPEG comes via a
Uri. You get such a
Uri quite frequently from
and all the time from
ACTION_OPEN_DOCUMENT. For compatibility with
other apps (e.g., email clients), you may support
<intent-filter>, or need to deal with them in
reading streams in your
ACTION_SEND activity, etc.
Some developers attempt to handle this by trying to hack some way to get
the filesystem path behind the
Uri. Such developers desperately need
to be slapped with a trout. There is no requirement that a
Uri be backed
by a file on the filesystem, let alone one that you can access and read.
Some developers wind up making a copy of the content as a local file,
just to feed it to
What makes all of this sad is that Android has had better EXIF tag
code for years. This includes support for processing tags from
InputStream, such as the one you might get via
for the JPEG identified by a
Uri. The class that provides this support
even has a familiar name:
It’s just a different
What is even more bizarre is that Google has copies of
ExifInterface in several projects, rather than consolidating on
one that everybody can access, including us lowly Android app developers.
- And the
It would be lovely if one of those would make it into the Android Support Library.
Even without that, though, if you need to read EXIF tags, consider using
one of those implementations, rather than going through all sorts of
shenanigans to get your JPEG into a local file, just to be able to use
the SDK’s limited
Want an expert opinion on your Android app architecture decisions? Perhaps Mark Murphy can help!Tweet