IssueTracker

Please include a sample project that reproduces your issue.

Hello I raised similar issue with this ticket https://issuetracker.google.com/issues/249247706

This makes the SearchView unusable/broken when fragments are changed (i.e base on searchView input query)

What can we do to fix this problem? What is the progress of work on solving this problem?

This has been fixed internally and will be available in the Fragment 1.6.0-alpha07 release.

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.fragment:fragment:1.5.6

@21 androidx.fragment:fragment:1.5.6 is a STABLE release. It has the fix we need. The androidx.fragment:fragment:1.6.0-alpha07 is an alpha as it says. 1.6 is "work in progress". 1.6.0 is still not a stable release. Use "alpha" only for testing

What we did in iNaturalist is force a file browser that then lets us retrieve EXIF metadata. But since it's just generic file browser, inside its side menu, users weren't able to choose "Google Photos" as the source of the images. So what we did was a hybrid approach -

1. First, display an intent chooser - either built-in file browser or Google Photos (if installed).
2. Then show the appropriate app.

Intent galleryIntent = new Intent();
galleryIntent.setType("image/*");
galleryIntent.setAction(Intent.ACTION_OPEN_DOCUMENT);
galleryIntent.addCategory(Intent.CATEGORY_OPENABLE);

Intent pickIntent = new Intent(Intent.ACTION_PICK);
pickIntent.setType("image/*");

Intent chooserIntent = Intent.createChooser(pickIntent, "Import photos from");
chooserIntent.putExtra(Intent.EXTRA_INITIAL_INTENTS, new Intent[]{galleryIntent});
startActivityForResult(chooserIntent, CHOOSE_IMAGES_REQUEST_CODE);

This whole issue and use case actually just got worse, or at least more convoluted, with the Oct. 2023 announcement of Google Play's new Photo and Video Permissions policy (https://support.google.com/googleplay/android-developer/answer/14115180?sjid=7767112419204292656-NC):

From their policy announcement:

• October 2023: We announced the new Photos and Video Permissions policy.

• Mid 2024: Apps with one-time or infrequent use of photos requested to use a system photo picker and remove READ_MEDIA_IMAGES and READ_MEDIA_VIDEO permissions from their app manifest.

• Early 2025: Only apps with broad access core functionality can use READ_MEDIA_IMAGES and READ_MEDIA_VIDEO permissions.

And a couple of items from their FAQ:

What does it mean to have a one-time or infrequent use of photos or video files?

Examples of one-time or infrequent use of photos or video files include, but are not limited to, uploading a profile picture, uploading an image for a playlist, or uploading a photo of a check for banking purposes. Infrequent use infers that your app does not have a photo or video use case as its core functionality. If your app has a one-time or infrequent use case for photo or video files, you may not use the READ_MEDIA_IMAGES or READ_MEDIA_VIDEO permission, and we urge you to instead use a system picker to preserve user privacy.

What kinds of apps would need "broad access to photos?"

Apps whose core function includes editing, managing, and maintaining photo or video galleries would need broad access to photos and videos on a user’s device. These apps are commonly known as "gallery apps."

So, if an app does not meet their photo "gallery app" requirement, Google appears to want to force everyone to use this new "safe" photo picker, which intententionally redacts EXIF location detail in the spirit of user privacy and safety, even after the user has granted appropriate permissions for said data.

In our case, we migrated to the new photo picker until we realized it removes EXIF info and then switched back to our old photo picker implementation (detailed in one of the valid use case reports above). Our old implementation requires READ_MEDIA_IMAGES or READ_MEDIA_VIDEO permissions and will potentially be broken when this new policy goes into effect unless Google excepts our app as needing broad access to photos. And our app is not a photo gallery type of app, but for our users that add photos to the app (some with every single use, and sometimes several dozen or more photos) and require EXIF location data to be available with the photos, this would make our app (and likely any competing Android apps) unusable.

Hey Google, how about you let the user decide what they want to allow, and don't take the stance that users must be so dumb that you need to make the decision for them, thus breaking actual core functionality in all of these use cases. That's when you'll really have angry users, but the app developers/providers are the ones that will take the hit.

Nutty approach by google IMO. I arrive to the thread NOT as native app developer but as a prototyper looking to combine AI photo classification with EXIF/GPS parsing.
ie submit a photo -> AI and EXIF tell you what type photo ( dog or cat ) and where ( Lat/lng st. addr )

Since its generic and prototype I attempted to implement the chooser via HTML in using 2 options below :

 <input type="file" accept="image/*"  />  
OR  
<input type="file" />  

opt-1 results in photo picker on Android 14/ Chrome
2nd option above results in intent dialog where you can select the camera to take photo

analyse on Android 14 re #1 or #2 above i found the following regarding Exif.gps implementation by the OS/browser:

1. -> photopicker buttons labels "Photos" or "Albums" and the 3-dot hamburger menu Photo button & Albums button result in the OS stripping GPS fields GPSLatitudeRef, GPSLongitudeRef While leaving intact numeric values for Longitude/latitude ( A BUG NOT A FEATURE ) BUT selecting the 3 dots brings up a more generic file list from which: a selected PHOTO WILL PASS ALONG ALL EXIF.GPS just fine

2. with just the type=file in the input tag, you get an intent chooser at the device level allowing you to select Camera taking a new photo. On submit of this foto all GPS data is preserved.

i filed a Chromium bug but it does not look like it will be addressed.

star the bug at the link if you care to

Do we really have to code and maintain our own photo picker library to get things like image location @Google? One would assume a modern mobile operating system would provide a streamlined way to pick photos - guess after almost 15 years this problem is still too hard to solve for the devs at google, eh? 😉

Same problem here. Our appp stores the pictures itself with location data to the gallery. But is not able to read them back later. It's annoying that there is no clear documentation and no solution to that.

We also build a data collection app (ODK Collect) and our users expect unmodified files. I would also expect that letting the user choose whether they want to allow ACCESS_MEDIA_LOCATION or not would allow them control over whether or not the app can read EXIF GPS info. Looking forward to a resolution here!

It's pretty crazy to think that one of the most basic features of a smartphone since 2008 (pick photos from the gallery) is still broken in 2024, 16 years later. Insane.

Wouldn't it be the better and correct way to solve this by declaring the usage of the `READ_MEDIA_IMAGES' permission, as described in Details on Google Play's Photo and Video Permissions policy?

Therefore, go to the Play Console -> Monitor and improve -> Policy and programmes -> App content and declare the usage of the permission.

Be aware that there is deadline for doing so: 22 Jan 2025

+1 to add capability to read EXIF data.

it's fine if it's not exposed per default, but the PhotoPicker should have the ability to prompt a permission(?) to read that data.