IssueTracker

Re comment#2 and comment#3 - this issue is only tracking the integration of bottom sheets into Navigation Compose so that you can use navController.navigate() to make a bottom sheet appear.

If you'd like to request changes to the ModalBottomSheetLayout and similar APIs, you'll want to file a separate request against Compose.

Fwiw this change does enable treating bottom sheets more like a window-esque thing, but they definitely won't be local.

Accompanist now supports this with Navigation Material.

Until this is implemented, could we at least get a warning notice in the documentation?

Not great to find out half way through a migration that this isn't possible.

Looks like we'll need to rework our app's navigation system (currently based on Fragments) just to support bottom sheets with a Bottom Navigation Bar at first glance. From the docs this wasn't clear.

Re comment#6 - can you explain what you are talking about? A fragment based navigation system is not going to be using Navigation Compose, which is what this issue is about and which is already available via Accompanist Navigation Material to unblock any migration to Navigation Compose from a fragment based system.

BottomSheetDialogFragment, which is what you'd use in a fragment based system, has been supported since dialog destinations were added in Navigation 2.1.0-alpha03 back in 2019.

This has been added internally and will be released as part of the compose.material library, not navigation.

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

• androidx.compose.material:material:1.7.0-alpha04
• androidx.compose.material:material-android:1.7.0-alpha04
• androidx.compose.material:material-desktop:1.7.0-alpha04

I guess the release that addresses this is actually: androidx.compose.material:material-navigation:1.7.0-alpha04

As #13 said, we are missing this for Material3 bottom sheets. I see that there's another issue tracking that here: https://issuetracker.google.com/issues/328949006

Some guidance about usage would be very welcome. I get java.lang.IllegalStateException: Could not find Navigator with name "bottomSheet". You must call NavController.addNavigator() for each navigation type. crash and can't find any proper example of this new extension usage:

                Scaffold(
                    bottomBar = {...}
                      
                ) { innerPadding ->

                    NavHost(
                        navController,
                        startDestination = "explore_graph",
                        Modifier.fillMaxSize()
                    ) {
                        // nested graphs

                        bottomSheet("profile_bottom_sheet") { // CRASHES
                            Text("Bottom Sheet", Modifier.padding(16.dp))
                        }
                    }
                }
            }
        }
    }
}

I use androidx.compose.material:material-navigation:1.7.0-beta01, but my project is material3, could it be the reason?

I really hope this will be picked up again: please either just include the exif location data again or allow for a way to additionally ask the user for permission to read the location of photos. All the previous comments show how many valuable apps rely on this.

For anyone looking for a workaround in the meantime: At komoot we basically put the new photo picker behind a feature flag and for the time being switched back to the old intent way that shows as a less nice looking photo picker, but at least allows the users to benefit from our full feature flow. The following is a snippet which Intent we use as fallback. Leaving it here in case it can help others:

private fun getFallbackAction(context: Context) = if (isPhotoPickerAvailable(context)) {
        // Ensure we do fully fall back to the pre photo picker. Not always supporting selecting multiple
        // Idea: split usages where we need photo GPS information. We could use this old-style look only for those cases instead, but might look confusing to users to see different picker styles in different flows
        Intent.ACTION_PICK
    } else {
        // More options to select from & guaranteed to work when selecting multiple at once
        // todo Important: using new picker with custom contract with Intent.ACTION_GET_CONTENT instead of a default one
        //  (e.g. getSingleVisualMediaContract) allows us to access a more powerful menu via three dots.
        //  this library is truly weird, but as long as it doesn't grant us GPS info we don't care about it.
        Intent.ACTION_GET_CONTENT
    }

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.