Status Update
Comments
ni...@gmail.com <ni...@gmail.com> #2
Related to
ra...@google.com <ra...@google.com>
an...@google.com <an...@google.com> #3
Project: platform/frameworks/support
Branch: androidx-main
Author: Marcello Galhardo <
Link:
Add MutableStateSerializer
for serializing MutableState
Expand for full commit details
Add `MutableStateSerializer` for serializing `MutableState`
- Introduced an inline `MutableStateSerializer` function to infer and retrieve the appropriate `KSerializer` for `MutableState` of a serializable type.
- Added an overload of `MutableStateSerializer` that accepts an explicit `KSerializer` for the wrapped type, allowing for customizing the `KSerializer`.
- Implemented `MutableStateSerializerImpl`, a private class that handles the serialization and deserialization logic for `MutableState`, delegating inner value processing to the provided `KSerializer`.
- Only `KSerializer<MutableState<T>>` is exposed; the `MutableStateSerializerImpl` remains private.
RelNote: "Add `MutableStateSerializer` for serializing `androidx.compose.runtime.MutableState`."
Test: MutableStateSerializerTest
Bug: 378895074
Change-Id: Idfc489d9313461bddd0046052d0f6a41644e7712
Files:
- M
lifecycle/lifecycle-viewmodel-compose/api/current.txt
- M
lifecycle/lifecycle-viewmodel-compose/api/restricted_current.txt
- M
lifecycle/lifecycle-viewmodel-compose/build.gradle
- A
lifecycle/lifecycle-viewmodel-compose/src/androidInstrumentedTest/kotlin/androidx/lifecycle/viewmodel/compose/serialization/serializers/MutableStateSerializerTest.android.kt
- A
lifecycle/lifecycle-viewmodel-compose/src/commonMain/kotlin/androidx/lifecycle/viewmodel/compose/serialization/serializers/MutableStateSerializer.kt
Hash: d628386123647d7f90b6efb2ddde93621c7cc7db
Date: Fri Jan 17 11:18:40 2025
co...@google.com <co...@google.com> #4
Project: platform/frameworks/support
Branch: androidx-main
Author: Marcello Galhardo <
Link:
Move KMP compatible test dependencies to commonTest
Expand for full commit details
Move KMP compatible test dependencies to `commonTest`
Test: N/A
Bug: 378895074
Change-Id: I77d03d1da41808e03d5e2978b768dc3ef6649211
Files:
- M
lifecycle/lifecycle-viewmodel-compose/build.gradle
Hash: e266fa197c54fe55955b2de9acc1c1d9894e6376
Date: Fri Jan 17 14:25:48 2025
ni...@gmail.com <ni...@gmail.com> #5
Project: platform/frameworks/support
Branch: androidx-main
Author: Marcello Galhardo <
Link:
Move MutableStateSerializer
to savedstate-compose
Expand for full commit details
Move `MutableStateSerializer` to `savedstate-compose`
- This change moves `MutableStateSerializer` from `lifecycle-viewmodel-compose` to `savedstate-compose`. This corrects its previous misplacement and aligns with the design outlined in go/savedstate-compose, which specifies that all `savedstate-compose` related APIs should reside within the `savedstate-compose` module.
RelNote: "Move `MutableStateSerializer` to `savedstate-compose`."
Test: MutableStateSerializerTest
Bug: 378895074
Change-Id: I4f690e41dc5619d185784409170943abeb0f0550
Files:
- M
lifecycle/lifecycle-viewmodel-compose/api/current.txt
- M
lifecycle/lifecycle-viewmodel-compose/api/restricted_current.txt
- M
savedstate/savedstate-compose/api/current.txt
- M
savedstate/savedstate-compose/api/restricted_current.txt
- M
savedstate/savedstate-compose/src/androidInstrumentedTest/kotlin/androidx/savedstate/compose/serialization/serializers/MutableStateSerializerTest.android.kt
- M
savedstate/savedstate-compose/src/commonMain/kotlin/androidx/savedstate/compose/serialization/serializers/MutableStateSerializer.kt
Hash: f845eabb6c5e3b138059839e59f383f70304d792
Date: Wed Jan 29 11:31:04 2025
co...@google.com <co...@google.com> #6
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.lifecycle:lifecycle-viewmodel-compose:2.9.0-alpha10
androidx.lifecycle:lifecycle-viewmodel-compose-android:2.9.0-alpha10
androidx.lifecycle:lifecycle-viewmodel-compose-desktop:2.9.0-alpha10
androidx.savedstate:savedstate-compose:1.3.0-alpha08
androidx.savedstate:savedstate-compose-android:1.3.0-alpha08
androidx.savedstate:savedstate-compose-jvmstubs:1.3.0-alpha08
androidx.savedstate:savedstate-compose-linuxx64stubs:1.3.0-alpha08
ni...@gmail.com <ni...@gmail.com> #7
Thank you for your feedback. I would definitely argue in favour of having access to that kind of metadata through the improved picker UI. And yes, I am aware that not all images will have that specific information.
co...@google.com <co...@google.com>
ba...@gmail.com <ba...@gmail.com> #8
According to
Therefore, I believe the new Photo Picker's behavior is not consistent with Google's documentation, thus becoming useless to many apps that rely on location info that may be stored in the EXIF.
The Photo Picker should be fixed to meet the correct behavior and to become consistent with the documentation.
Thanks.
bu...@gmail.com <bu...@gmail.com> #9
In our use case (iNaturalist), we need to read EXIF data to show the location the photo of the observation was taken at.
We cannot use this component otherwise.
ma...@gmail.com <ma...@gmail.com> #10
If the application has the rights to access the file, why limit it's access to the metadata of the file? The location in the metadata isn't correlated in any way to the user location unless the user just took the picture. It seems like the better approach would be to make it clear to users when EXIF data is attached to an image - not break previously working implementations of the file picker.
ma...@fastfieldforms.com <ma...@fastfieldforms.com> #11
But for an actual use case example: Our customers are mostly field service personnel, and collect and document important site data while in the field, some of it safety related or location-specific documentation or real estate related, and they are depending on their EXIF data in which they have already enabled on their photos, to be available when they import those photos into our application. You redacting that data is not much different from say for example, implementing some kind of fuzzing feature on some type of content in the photos because you consider it a privacy risk. Well, it's not. Stop making judgement calls and assumptions and focus on cool components instead (which this seems to be except for this problem). The user has already worked to get EXIF information into their photos in our case, and expects that data to remain with the photo throughout our app's process.
Please update this component to NOT touch the EXIF data if the user has granted the required and documented permissions. This new Photo Picker component is completely useless without it. I'll be going back to the third party component I was using before I wasted several hours today migrating everything over to your new component offering, before realizing my customer's EXIF data was gone.
This seems to be a continuing pattern at Google. With every SDK update you are heaping more and more restrictions on to available functionality, and it usually results in us having to do a bunch of extra work to keep our customers happy, without eliminating or breaking the functionality they have had for years.
jo...@gmail.com <jo...@gmail.com> #12
I thought this new photo picker would solve all the problems we've had over the years, but no, this thing doesn't solve anything but another person's OKRs. And increased package size.
lu...@gmail.com <lu...@gmail.com> #13 Restricted
hu...@gmail.com <hu...@gmail.com> #14
GPS data is essential for us, our goal is to build a plant biodiversity database. Without the geolocation of the plant, the photo itself is useless, and we cannot use the GPS chip from the device as the photos may have been taken in another location.
The data is published as open data on GBIF.org, as well as data coming from iNaturalist, which have the exact same issue.
Pl@ntNet is one of the major contributor of open data for plants, where the data is used to analyse climate change and biodiversity conservation by researchers around the world. 30M users in the last 2 years can produce a lot of data.
nb...@a8c.com <nb...@a8c.com> #15
We hope that you reconsider this "Won't fix (Intended behavior)" stance. This is important to both us and our users.
ia...@googlemail.com <ia...@googlemail.com> #16
ia...@googlemail.com <ia...@googlemail.com> #17 Restricted
co...@gmail.com <co...@gmail.com> #18
1. Users can choose whether or not to include their EXIF location in their media from their photo application.
2. The user can be asked for permission to obtain the location of the media when it is read via ACCESS_MEDIA_LOCATION (otherwise what's the point?).
=> It therefore seems contradictory to arbitrarily block any communication of location information in the media from the picker to say that this is the intended behavior.
All applications based on positioning in the media are impacted (mushroom picking, vacation photos on a map, and many professional applications of course...).
The logic in this case would be that no location information can be extracted from an Android Media application. Including Google Photo. Logic would also dictate that Google Photo has no access to media location either! Even if the user agrees to share this information.
I guess I'm not that logical.
au...@wonderment.com <au...@wonderment.com> #19
jo...@komoot.de <jo...@komoot.de> #20
br...@gmail.com <br...@gmail.com> #21
My project, which was featured on #WeArePlay (
My project is NoFilter (
You can try the app. It's free.
Some days ago I switched to this new photo picker, and practically none of the users can upload photos. All of them are reporting bugs, which I really thought it was a bug in Expo (
In my case, my users, are 100% OK with using the EXIF>Location data (actually.. that's THE ONLY thing the want from my app).
Is there any workaround we can implement?
In my case, or I implement a workaround, or I kill the project. I have no another option. This is not a "nice to have".
br...@gmail.com <br...@gmail.com> #22
Because this issue is closed as "Won't fix", so probably nobody is going to pay any kind of attention here.
fr...@komoot.de <fr...@komoot.de> #23
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
}
bu...@gmail.com <bu...@gmail.com> #24
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 -
- First, display an intent chooser - either built-in file browser or Google Photos (if installed).
- 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);
br...@gmail.com <br...@gmail.com> #25
ma...@fastfieldforms.com <ma...@fastfieldforms.com> #26
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 (
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.
ro...@gmail.com <ro...@gmail.com> #27
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:
-
-> 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
-
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
ro...@gmail.com <ro...@gmail.com> #28
star the bug at the link if you care to
hy...@gmail.com <hy...@gmail.com> #29
jk...@gmail.com <jk...@gmail.com> #30
am...@googlemail.com <am...@googlemail.com> #31
ki...@gmail.com <ki...@gmail.com> #32
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? 😉
gp...@gmail.com <gp...@gmail.com> #33
ni...@gmail.com <ni...@gmail.com>
am...@googlemail.com <am...@googlemail.com> #34
st...@speakap.nl <st...@speakap.nl> #35
I believe the fix should provide an easy way to configure the picker to wipe the EXIF info OR to keep it, depending on the use case. This should be a decision that the user makes through the application.
(I don't mind if there's ALSO a per-app override either in the picker itself, or in the OS settings somewhere, so that a user can configure it for apps that are not mindful of their privacy. But then this config should be available read-only to the app, so it can inform the user and ask them to disable the override, if needed. Similar to push notifications)
ro...@gmail.com <ro...@gmail.com> #36
We believe in it!
ma...@gmail.com <ma...@gmail.com> #37
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.
to...@googlemail.com <to...@googlemail.com> #38
go...@memoriesmap.com <go...@memoriesmap.com> #39
ed...@gmail.com <ed...@gmail.com> #40
EXIF metadata from photos is critical to build this, please can this be addressed?
wi...@gmail.com <wi...@gmail.com> #41
ln...@getodk.org <ln...@getodk.org> #42
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!
fe...@gmail.com <fe...@gmail.com> #43
ry...@gmail.com <ry...@gmail.com> #44
be...@gmail.com <be...@gmail.com> #45
If I simple pick the old way its working fine (ACTION_GET_CONTENT).
Btw, your fallback are also quite bad. Why?
2 out of the 3 fallbacks, ignore the EXTRA_ALLOW_MULTIPLE. And the worst problem is, that this 2 which ignore it, are the first one. So I cannot even use your fallback, because its not working like the users would expect. No, I have to check the Android version myself and then use the ACTION_GET_CONTENT way.
vi...@gmail.com <vi...@gmail.com> #46
gu...@journiapp.com <gu...@journiapp.com> #47
It is really urgent to fix this, otherwise this Google Play enforcement seems extremely anticompetitive and plain wrong. There is no privacy excuse here; you can always add the option to enable/disable location sharing in the system picker UI and let the users choose, but simply not supporting is not ok.
to...@googlemail.com <to...@googlemail.com> #48
ba...@werktools.com <ba...@werktools.com> #49
In view of the new permission policy this issue must be fixed before we can adhere to that policy.
go...@memoriesmap.com <go...@memoriesmap.com> #50
Everyone on this thread has an app that they're developing that requires location metadata, we ask users permission for this data, and Google's policy is blocking this, blocking the development of new products for our users. It is unfair and extremely Anti-competitive.
**I'd strongly recommend for everyone to read this from the EU Commissions Competition Policy:**
**And to send your own complaint to this email address:**
comp-market-information@ec.europa.eu
Perhaps they won't listen to a lone voice, but if all the app developers on this thread join together, Werktools, Memories Map, JourniApp, SpeakAp, FastFieldForms, KoMoot and Wonderment, we can get this resolved and continue to build excellent products for our users using their data that they consent to provide us with. Together we could even bring some kind of class act lawsuit against Google.
go...@memoriesmap.com <go...@memoriesmap.com> #51
br...@gmail.com <br...@gmail.com> #52
I think it would be good if somebody propose a text to send, and then we all send it the same day. Because if we send the complains 1 per month, it won’t create an impact. It should be a waterfall of inquiries in the same day.
Let’s define a text, and a day.
Is it possible to create an public “invite” file? If so, let’s create it and add it to our calendars.
Good catch, btw.
to...@googlemail.com <to...@googlemail.com> #53
go...@memoriesmap.com <go...@memoriesmap.com> #54
Send your emails on Friday 8th November to comp-market-information@ec.europa.eu
Subject: Anti-competitive behaviour from Alphabet/Google relating to photo data access
Text:
Hi there,
[INSERT THE APP / PRODUCT YOU'RE DEVELOPING AND WHY IT REQUIRES PHOTO LOCATION METADATA].
The problem is this; google has a policy which does not allow developers to get photo location data. When users take photos on their phone, it records locations usually so this data does exist, but when apps try to get this data, they strip out only the location metadata. This blocks other companies from building products with this data, and is harming my business because I require users who consent to provide me with their photo metadata.
In their own developers documentation:
Their policy states:
Do not use this API to create, train, or improve (directly or indirectly) similar or competing products or services.
There is an issue log here with Google:
My details are:
Name: YOUR_NAME
Address: YOUR_ADDRESS
Firm: Alphabet/Google
Products: Android image picker/Google Photos API/Google app developer policies
vi...@gmail.com <vi...@gmail.com> #55
ki...@gmail.com <ki...@gmail.com> #56
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.
mm...@gmail.com <mm...@gmail.com> #57
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
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
Description
Hello,
I'm writing an app targeting Android 13 (SDK 33) and have tested on Android 11, 12 and 13.
I'm trying to use the new photo pickerhttps://developer.android.com/training/data-storage/shared/photopicker in an app targeting SDK 33 (Android 13).
The
Uri
returned from that looks like this:content://media/picker/0/com.android.providers.media.photopicker/media/1000000082
.I am unable to retrieve GPS location data using
ExifInterface
usingAnd
MediaStore.setRequireOriginal(uri)
throws aSecurityException
with messageCalling uid does not have permission to access picker uri: content://media/picker/0/com.android.providers.media.photopicker/media/1000000082?requireOriginal=1
However when I use the
GetContent
contract instead of the new pickerThe
Uri
looks likecontent://com.android.providers.media.documents/document/image%3A1000000049
and the GPS position exists in the EXIF data.When using the photo picker API on devices where it is not yet available it switches to
Intent(Intent.ACTION_OPEN_DOCUMENT)
internally which has identical behaviour to theGetContent()
contract as well and I am able to pull GPS data.I've found that some documentation talks about the
ACCESS_MEDIA_LOCATION
permission and have tried granting any combination ofACCESS_MEDIA_LOCATION
,READ_MEDIA_IMAGE
andREAD_EXTERNAL_STORAGE
permission as well, but to no avail. It is worth noting that none of those permissions and neitherMediaStore.setRequireOriginal(Uri)
are needed when using theActivityResultContracts.GetMultipleContents()
contract.What is happening here? What is the correct way to retrieve images using the new photo picker without EXIF data being redacted? Hopefully without having to ask the user permission for "access to all images and videos" on the device, since I already have access to the image I need.