@capacitor/camera 6.0.1 pickImages results has zeros/empty in exif GPS data on Android

[danbritt]

Bug Report

Plugin(s)

@capacitor/camera 6.0.1

Capacitor Version

   Capacitor Doctor

Latest Dependencies:

  @capacitor/cli: 6.1.0
  @capacitor/core: 6.1.0
  @capacitor/android: 6.1.0
  @capacitor/ios: 6.1.0

Installed Dependencies:

  @capacitor/ios: not installed
  @capacitor/cli: 6.1.0
  @capacitor/android: 6.1.0
  @capacitor/core: 6.1.0

[success] Android looking great! 👌

Platform(s)

Android. Tested on physical device with Android 12 and 14

Current Behavior

When you select a photo that has a location, the exif data returned has zeros/blanks in all the GPS properties. So it appears the GPS data is actually missing for some reason. Example:

{
  ...
  "GPSAltitude": "0/1",
  "GPSAltitudeRef": "0",
  "GPSDateStamp": "",
  "GPSImgDirection": "0/1",
  "GPSImgDirectionRef": "",
  "GPSLatitude": "0/1,0/1,0/1",
  "GPSLatitudeRef": "",
  "GPSLongitude": "0/1,0/1,0/1",
  "GPSLongitudeRef": "",
  "GPSTimeStamp": "00:00:00",
  "GPSVersionID": "\u0000\u0000\u0000\u0000",
  ...
}

Expected Behavior

I would expect the GPS information to have the proper values.

Code Reproduction

Minimal example app: https://github.com/danbritt/capacitor-photo-picker-example

Other Technical Details

Additional Context

I've also attempted to retrieve the file from the path returned using the Filesystem plugin, and then read the exif using a different npm package. I got the same result with the missing/zero'd out GPS properties.

[ryaa]

@danbritt
In Android with SDK >=29, you need ACCESS_MEDIA_LOCATION permission.
Make sure to request for permission before pick image and then GPS should return correctly. Or you can always add it yourself using this plugin https://github.com/capacitor-community/exif

[danbritt]

I found an older issue about this problem where someone recommended doing that and it did not work for me. If you can make the example work by doing that, please fork the repo and post a link to the working one.

Thank you for the link to that plugin. I will give it a try to fix the issue. However, I still feel that the Camera plugin should provide this functionality since it does return the exif data as one of the properties in the result.

[danbritt]

I had some time today to try to implement that plugin on the project I'm working on. I do have that permission in my AndroidManifest.xml, but getCoordinates() is returning undefined instead of the lat/lon values.

I appreciate the attempt to solve the issue!

What's odd is that this only applies when picking photos from the photo album. If I use the camera plugin to capture a photo, the GPS info is present in the exif data. Same if I choose a non-album image (using the FilePicker plugin from https://github.com/capawesome-team/capacitor-plugins)

[ryaa]

@danbritt I confirm the problem with the camera plugin getPhoto method not including GPS coordinates in the returned EXIF metadata. I tested this on my Android and even though the photo has the coordinates and the Android manifest includes <uses-permission android:name="android.permission.ACCESS_MEDIA_LOCATION" /> permission, the returned result don't have the coordinates. I will try to research this more and will follow up with my findings...

[danbritt]

That is very interesting. For me, getPhoto returns the GPS data in the exif, but pickImages does not.

[ryaa]

@danbritt it seems that the problem is because the new photo picker (which is used in Capacitor Camera v6 - see https://capacitorjs.com/docs/updating/6-0#camera) redacts GSP data from EXIF, even when ACCESS_MEDIA_LOCATION permission is present. More details can be found here https://issuetracker.google.com/issues/243294058?pli=1

I am not sure how that can be fixed, unless Capacitor Camera switch to use some alternative instead of the google photo picker API.

NOTE: this file picker seems to return GPS data in EXIF (see https://capawesome.io/plugins/file-picker/) as it uses Intent.ACTION_PICK approach.

[danbritt]

@ryaa

Thanks for the research and information you presented. I will try swapping to the capawesome plugin.

[danbritt]

@ryaa I swapped to using the capawesome plugin and it works great. Thanks again for the suggestion and the research on the underlying issue!

[eric-horodyski]

This thread has been inactive for some time, and we’re cleaning up older items to keep the backlog focused and manageable.

Details on the effort:
https://ionic.io/blog/keeping-capacitors-backlog-healthy

If this is still relevant today, feel free to open a new issue with current information and we’ll review it.

[ryaa]

@eric-horodyski I understand the backlog cleanup, but I’m a bit concerned about the loop here: this issue wasn’t resolved, and it’s being closed due to inactivity rather than a decision on the underlying behavior. If I open a new issue with repro details, what’s the best way to ensure it doesn’t just sit for a long time and then get closed again the same way?