IssueTracker

Project: platform/frameworks/support
Branch: androidx-main

commit b6c7c78f9e7476b468dafe9d5f7dec6794d47f09
Author: Shahd AbuDaghash <shahddaghash@google.com>
Date:   Mon Nov 27 11:16:51 2023

    Introduce DecayAnimation in AnchoredDraggable
   
    Decay animation allows more realistic settling of a component. This is performed by now passing a `DecayAnimationSpec` parameter to AnchoredDraggable and using it when animating to the target. The new animation implementation will be added in a chain CL.
   
    Bug: 288084801
    Test: Tests will be added in a chain CL
    Relnote: This change adds a `decayAnimationSpec` parameter to AnchoredDraggable allowing to use decay animation when settling to one of the anchors. The change also includes renaming the existing `animationSpec` to `snapAnimationSpec` to help understanding the use case of each spec.
    Change-Id: I44ccd408d919328fd6504d31d8db59cf1d07de43

M       compose/foundation/foundation/api/current.txt
M       compose/foundation/foundation/api/restricted_current.txt
M       compose/foundation/foundation/samples/src/main/java/androidx/compose/foundation/samples/AnchoredDraggableSample.kt
M       compose/foundation/foundation/src/androidInstrumentedTest/kotlin/androidx/compose/foundation/anchoredDraggable/AnchoredDraggableGestureTest.kt
M       compose/foundation/foundation/src/androidInstrumentedTest/kotlin/androidx/compose/foundation/anchoredDraggable/AnchoredDraggableStateTest.kt
M       compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/AnchoredDraggable.kt

https://android-review.googlesource.com/2847074

Project: platform/frameworks/support
Branch: androidx-main

commit ff1a600df5f4d8ae21a75d8e3e0f24d6c5c2faee
Author: Shahd AbuDaghash <shahddaghash@google.com>
Date:   Mon Nov 27 15:51:12 2023

    Modify settle function to perform decay animation if possible
   
    When settling, a check will be performed to see if natural decay animation can be used. If not so, a target animation will be used. The consumed velocity is returned to the settle function, which could be used to show an overscroll effect.
   
    Bug: 288084801
    Test: Tests will be added in a chain CL.
    Relnote: This change introduces a new `animateToWithDecay` function that naturally decays if possible. It takes the target value and the initial velocity. The `animateTo` functions no longer takes a velocity, but passes the available velocity in `lastVelocity` to animation, as it is concerned with reaching the target. If users need to pass a certain velocity for animation, they can use `animateToWithDecay` function.
    Change-Id: I465dbd826e3969b784d08c65425f4bbda3de8493

M       compose/foundation/foundation/api/current.txt
M       compose/foundation/foundation/api/restricted_current.txt
M       compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/AnchoredDraggable.kt

https://android-review.googlesource.com/2847576

Project: platform/frameworks/support
Branch: androidx-main

commit 01142ddd5b14eb33e5145c4e72e6619a5c100fe4
Author: Shahd AbuDaghash <shahddaghash@google.com>
Date:   Thu Dec 21 12:34:00 2023

    Introduce Overscroll in AnchoredDraggable
   
    Adding overscroll support to AnchoredDraggable by giving the ability to pass a customized overscrollEffect object to AnchoredDraggable.
   
    Bug: 288084801
    Relnote: An OverscrollEffect has been introduced to allow for custom overscroll effects in anchoredDraggable. To retrieve the consumed velocity after animation, the consumed velocity is returned from the settle function.
    Test: Added tests to verify behavior
    Change-Id: I100683fe7473b1e5ff317ab22245a2b0a25bd549

M       compose/foundation/foundation/api/current.txt
M       compose/foundation/foundation/api/restricted_current.txt
M       compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/AnchoredDraggableDemo.kt
M       compose/foundation/foundation/samples/src/main/java/androidx/compose/foundation/samples/AnchoredDraggableSample.kt
A       compose/foundation/foundation/src/androidInstrumentedTest/kotlin/androidx/compose/foundation/anchoredDraggable/AnchoredDraggableOverscrollTest.kt
M       compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/AnchoredDraggable.kt

https://android-review.googlesource.com/2888106

Project: platform/frameworks/support
Branch: androidx-main

commit 0f071d797bccf7eff2a23e408928ca76640af782
Author: Shahd AbuDaghash <shahddaghash@google.com>
Date:   Wed Nov 29 18:34:09 2023

    Migrates AnchoredDraggable to Modifier.Node
   
    Migrates AnchoredDraggable to Modifier.Node. This helps in adding Overscroll effect in AnchoredDraggable.
   
    Bug: 288084801
    Test: Added tests to verify behavior
    Change-Id: I3f3338cd71763972c4b70f2e06c97e85285b0035

M       compose/foundation/foundation/src/androidInstrumentedTest/kotlin/androidx/compose/foundation/anchoredDraggable/AnchoredDraggableGestureTest.kt
M       compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/AnchoredDraggable.kt
M       compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/Draggable.kt
M       compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/gestures/Draggable2D.kt

https://android-review.googlesource.com/2852691

This is not a transient issue.  We discovered it 2 days ago and it's getting worse every day.  The pool of addresses that are no longer working is growing.

Someone at Google should consider this a showstopper, it's getting worse everyday.

I have the same issue with increasing regularity. This is a critical production bug.

[Comment deleted]

Same issue starting to show up 12/21/2016 for following addresses,
38 E21 st, new york, ny
800 5th ave, brooklyn ,ny
220 riverside blvd, new york, ny
1234 fulton st, brooklyn, ny
31 west 52nd st, new york, ny
712 3rd ave, brooklyn, ny

Those just 6 samples.   There are lot more addresses having the same geocoding issue.

This is an OUTAGE situation.  Need FIXES NOW PLEASE

Can confirm we're getting a huge increase in complaints since yesterday about this issue too. An update would be appreciated.

Can we have an official statement regarding this issue ?

This starts to be *really* frustrating.

We reckon this is a severe issue affecting US address, and are working on releasing a fix for this in the coming days.

What is the latest status on this issue please???  We will have to move to another mapping service if you cannot resolve in a timely fashion.

-David

You have paying customers whose businesses are taking a hit.  Can someone at Google take a moment and provide an update so we can set expectations with our own customers please.

Same here, my clients are going insane!!!!!!!

Any ETA for the fix? Please let us know.

We are currently rolling out a fix, it should be available everywhere within a couple of hours, maybe sooner.

Autocomplete will soon start returning longer place ids for the affected addresses, here is an example:

"13301 South Main Street, Los Angeles" currently returns place_id: "ChIJs_yHGELKwoARSuzreEXG9sQ":
https://maps.googleapis.com/maps/api/place/autocomplete/json?input=13301%20S%20Main%20St,%20Los%20Angeles

Soon, place_id will be "ChIJs_yHGELKwoARSuzreEXG9sSaBjcxMzMwMSBTb3V0aCBNYWluIFN0cmVldCwgTG9zIEFuZ2VsZXMsIENBLCBVbml0ZWQgU3RhdGVz"

Place Details already accept such longer place ids:

https://maps.googleapis.com/maps/api/place/details/json?placeid=ChIJs_yHGELKwoARSuzreEXG9sSaBjcxMzMwMSBTb3V0aCBNYWluIFN0cmVldCwgTG9zIEFuZ2VsZXMsIENBLCBVbml0ZWQgU3RhdGVz
formatted_address: "13301 S Main St, Los Angeles, CA 90061, USA",
name: "13301 S Main St",
place_id: "ChIJ8VusGELKwoARyuJubm8OGkw",

Note the short place_id in the Details response. Place Details will return the correct result for such place_id.

There is a caveat for those using Place Autocomplete in combination with Geocoding, Directions or Distance Matrix API: these longer place ids will not be found by any of these APIs.
These APIs will return ZERO_RESULTS, just the same as with the old short place ids (i.e. ChIJs_yHGELKwoARSuzreEXG9sQ). The new short place ids (i.e. ChIJ8VusGELKwoARyuJubm8OGkw) will yield correct results, which means the following query flow will be fixed: Place Autocomplete => Place ID => Place Details => Place ID => Directions / Distance Matrix

If you are using the JavaScript Autocomplete class with the new placeIdOnly option, and then using Place IDs to request Directions, the current fix will not help you. However, by just removing the placeIdOnly option, thins should work well again.

Please file a new bug if this is a problem for any of you and we'll look at it separately.

Concerned that this issue shows as resolved. Our ticket was merged into this and all the addresses we are having issues with are still not functioning properly.

Steps to Reproduce:
1. Go to https://developers.google.com/maps/documentation/javascript/examples/places-autocomplete-addressform
2. Enter address - 1063 McGaw Avenue, Irvine, CA
3. Select suggestion from list
4. Notice that address is not parsed below.

This used to work prior to this bug and is still not working since the bug has been marked Fixed.

Same here. Many addresses still failing for us and causing errors for users.

It appears that the fix is not fully rolled out. The example provided by the Google team member, "13301 South Main Street, Los Angeles" still returns place_id: "ChIJs_yHGELKwoARSuzreEXG9sQ".

Can you update with information on the rollout status and when we can expect to see the service working as expected?

There is no way to accurately predict how long a global rollout will take. Best we can tell is: couple of hours, maybe sooner.

UPDATE: rollout is about 70% complete globally, we expect it to be 100% within the hour.

Out of curiosity, why couldn't you guys roll-back to a working-snapshot in these past 4-days?  Also when can we expect Reference ID to be fully removed/deprecated?  Using Reference did not run into this issue.

I'm wondering if this is the same issue we have started seeing in the last couple days where a business has verified and was showing up using the Places API but now we get ZERO RESULTS when searching for them.  For example this business detail exists:  https://maps.googleapis.com/maps/api/place/details/json?placeid=ChIJrdr_tigG3IARYRXNiLaZb5k

But that business cannot be found using the near by search with keyword equal to the business name after the weekend:

https://maps.googleapis.com/maps/api/place/nearbysearch/

Is this fixed as well?

Many of our users have stored (in our database) the Place IDs of certain locations. I assume the broken Place IDs will never be rerouted to the corrected Place IDs? Is there any way to cross-reference / convert them?

#37 please file a new bug, this one was never related to Nearby Search.

#38 Yes. No. I'm afraid those Place IDs will have to be discarded, users would have to repeat their searches to find the new Place IDs. These are expected to remain valid in the long term.

This changed several place ids for Cities being returned by google.maps.places.AutocompleteService();. However, google.maps.places.Autocomplete() still returns the short ids.

For instance Paris, France is now ChIJD7fiBh9u5kcRYJSMaMOCCwSaBg1QYXJpcywgRnJhbmNl instead of ChIJD7fiBh9u5kcRYJSMaMOCCwQ. Other google maps APIs still return the short id. Why was this changed and which should we be using?

#43 There's a difference because the long-ish place ids are only returned by Place Autocomplete.

google.maps.places.AutocompleteService directly returns results from Place Autocomplete.

google.maps.places.Autocomplete.getPlace returns the result of a Place Details lookup on the currently selected input, so it doesn't return the long-ish place id.

You should be able to use either place id with all the Maps APIs that accept place ids. However, if the place was affected by the original issue, only Place Details will be able to resolve the place [for now].

This is killing my taxi business!

Just wanted to let you know there were issues with UBER and LYFT not able to select an address because of your place-id implementation.  Awesome, great job guys!

[Comment deleted]

It seems all the `place_id`s being returned by the `Autocomplete` service can now be used in the `Geocoder` service in addition to `Place Details` service. I would really appreciate a response from Google whether we can continue to rely on `Geocoder`, or if we do need to switch to using `Place Details`. Thanks.

Was this issue addressed only wiht US addresses, or was this addressed Globally? I've been testing with an address, "34 Aldershot Road, Guildford, GU2 8AF, United Kingdom", and this API is still dropping the street number aspect of the address.

I feel that might be another issue tracked elsewhere or reportable through some other forum. The issue I believe this is tracking is when the `place_id` returned from the `autocomplete` service:

https://maps.googleapis.com/maps/api/place/autocomplete/json?input=34%20Aldershot%20Road,%20Guildford,%20GU2%208AF,%20United%20Kingdom&types=geocode&key=

Does not return ANY results, but your place_id (ChIJ-wrkCsbQdUgR8--nRmOq34A) does return ONE (bad) response with both Geocode and Place Details:

https://maps.googleapis.com/maps/api/geocode/json?place_id=ChIJ-wrkCsbQdUgR8--nRmOq34A&key=

https://maps.googleapis.com/maps/api/place/details/json?placeid=ChIJ-wrkCsbQdUgR8--nRmOq34A&key=

Excellent sounds good. I'll log this as a separate issue.

The placeId received from a place on Google Maps' `onPOIClick` event (PointOfInterest.placeId) is not the same as the one received from the Google Places API for the same place. Not sure what the intention with the inconsistent placeid implementation was but I'm really looking forward to a fix. Thanks google.

Here's a link to the report on stackoverflow - https://stackoverflow.com/questions/46139697/googlemaps-placeid-of-pointofinterest-not-the-same-as-one-from-api

This is still an issue for us.

There are placeId's that are returned from the autocomplete service, but when you put them in the /place/details/json, it says NOT_FOUND.

This is causing production issues for our environment...

For example: "Burnham, United Kingdom" returns placeId: ChIJI-k54YZkdkgRG4nprrZVv64 from the autocomplete service.
However, when looking this up in place/details: "NOT_FOUND" is returned

Same issue with "Salerno, SA, Italia" today.

placeId  from the autocomplete service is "ChIJiTC9NFfCOxMRoHQD2hOXpBU"

PlaceService.GetPlaceDetails returns "NOT_FOUND"

Confirming that this is still a bug. I am unable to see place details for "313 West 29th Street, New York, NY" on the Place Autocomplete page:

https://developers.google.com/maps/documentation/javascript/examples/places-autocomplete

(It throws an error dialog).

Still perists error also with ChIJCU1G2eriOBMRJbK1tMPe5zA (Potenza, PZ, Italy)

Having the same problem also:

##### Test 1 FAILED #####
Autocomplete place_id for "1098 Waters Avenue, Aspen, CO, USA": EiIxMDk4IFdhdGVycyBBdmVudWUsIEFzcGVuLCBDTywgVVNB

[MISMATCHED] Place Details returned "1098 Aspen Way, Broomfield, CO 80020, USA" place_id: EikxMDk4IEFzcGVuIFdheSwgQnJvb21maWVsZCwgQ08gODAwMjAsIFVTQQ

##### Test 2 FAILED #####
Autocomplete place_id for "Waters Avenue, Aspen, CO, USA": Eh1XYXRlcnMgQXZlbnVlLCBBc3BlbiwgQ08sIFVTQQ

[MISMATCHED] Place Details returned "Aspen Ave, Colorado Springs, CO 80905, USA" place_id: ChIJTwEyDoxEE4cRSZhhKVOjkKo

##### Test 3 FAILED #####
Autocomplete place_id for "1025 Waters Avenue, Aspen, CO, USA": EiIxMDI1IFdhdGVycyBBdmVudWUsIEFzcGVuLCBDTywgVVNB

[MISMATCHED] Place Details returned "1025 Aspen Way, Broomfield, CO 80020, USA" place_id: ChIJxcuZ6O2Ka4cRRVe_O2kBcDA

##### Test 4 OK #####
Autocomplete place_id for "1102 Waters Avenue, Aspen, CO, USA": ChIJqeOOq947QIcRYF9ZL4GtRjg
[MATCH] Place Details returned "1102 Waters Ave, Aspen, CO 81611, USA" place_id: ChIJqeOOq947QIcRYF9ZL4GtRjg

##### Test 5 FAILED #####
Autocomplete place_id for "1104 Waters Avenue, Aspen, CO, USA": EiIxMTA0IFdhdGVycyBBdmVudWUsIEFzcGVuLCBDTywgVVNB

[MISMATCHED] Place Details returned "1104 Aspen Dr, Evergreen, CO 80439, USA" place_id: ChIJY5647Hqia4cR3xe6TfgTrRc

Having major issues this morning.  our customers in and around chicago are having problems
EiMxODk4IFdpbmNoZXN0ZXIgQ3QsIE9zd2VnbywgSUwsIFVTQQ
- 1898 Winchester Ct, Oswego, IL

I have observed this issue as well today. First, I made a request to the Nearby Search API to obtain a place ID. Then, I made a request to the Place Details API using this place ID. The Place Details request returned a status of NOT_FOUND.

Reporting the same sort of problem but with the "Unknown_Error" response from geocoder. I've used the autcomplete service to search for the address and once user selects one, the place_id is not being found .. if I use the direct url then it reports the 'place_id is invalid'.

Observing this on the following Ids (and more). These were returned by autocomplete requests:

ChIJyygUO3TjjTkR8QP6yqDJykU
ChIJx4LCUpoEDTkRpDT3uvi1aPo
ChIJ_ZjPpfTz9DkR6cR7e_J7GM8
ChIJC8CDrrqUcjkRirqa0HO6_00

The detail request returns NOT_FOUND for most requests

I used place id from the autocomplete api response, in the /place/details api and got:
   {
       "html_attributions" : [],
       "status" : "NOT_FOUND"
    }

It happened to me in several addresses.
In some addresses i got a regular response  after i waited  2 minutes between autocomplete call and the
place details call.

Happening on 44 Latitude Boulevard, Thomastown VIC, Australia: EjA0NCBMYXRpdHVkZSBCb3VsZXZhcmQsIFRob21hc3Rvd24gVklDLCBBdXN0cmFsaWEiMBIuChQKEgnpMzCybU_WahHttzaUe6up6hAsKhQKEgkbqLQObU_WahHfpARI3kfqGg
This address worked previously.

Flow goes: Autocomplete -> place_id -> GetPlaceDetails with fields=address_component,place_id

i also have same issue ..
https://maps.googleapis.com/maps/api/place/details/json?key=xxxxxxxxxxxxxxxxxx&placeid=EiVTasO2dsOkZ2VuIDIxMSwgQXNraW0sIEhvdsOlcywgU3dlZGVu
{
   "html_attributions" : [],
   "status" : "NOT_FOUND"
}

#67 is actually https://issuetracker.google.com/35823492

#68 i think this is not related this.
 discription of this (" https://issuetracker.google.com/issues/35823492") is :
"Details for Place Autocomplete prediction is missing street number, or located a different locality"  
but in my case nothing is come in response.

Most of the times the result matches that description, but the very same issue (root cause) occasionally results in NOT_FOUND responses as well.

Trying to find : Jalan Safir Raya No.21, RT.8/RW.3, Srengseng, Kota Jakarta Barat, Daerah Khusus Ibukota Jakarta, Indonesia
with place_id : EmpKYWxhbiBTYWZpciBSYXlhIE5vLjIxLCBSVC44L1JXLjMsIFNyZW5nc2VuZywgS290YSBKYWthcnRhIEJhcmF0LCBEYWVyYWggS2h1c3VzIElidWtvdGEgSmFrYXJ0YSwgSW5kb25lc2lh
result :
{
    "html_attributions": [],
    "status": "NOT_FOUND"
}

ALSO

find : Jalan Safir Raya No.21, RT.13/RW.3, Bintara Jaya, Kota Bekasi, Jawa Barat, Indonesia
place_id : ElRKYWxhbiBTYWZpciBSYXlhIE5vLjIxLCBSVC4xMy9SVy4zLCBCaW50YXJhIEpheWEsIEtvdGEgQmVrYXNpLCBKYXdhIEJhcmF0LCBJbmRvbmVzaWE
result :
{
    "html_attributions": [],
    "status": "NOT_FOUND"
}

my client is going mad

I have the same issue. When I make a place details request for a place id that I have just get from an auto complete response, I get "NOT_FOUND" in the result.
Auto Complete Request : https://maps.googleapis.com/maps/api/place/autocomplete/json?input=Esentepe%20Mahallesi,%20%C5%9Ei%C5%9Fli/%C4%B0stanbul,%20T%C3%BCrkiye&key=*************&language=tr&components=country:tr
Place id: ChIJdSWkflu2yhQRBw4n2CqXwfg
Details Request: https://maps.googleapis.com/maps/api/place/details/json?placeid=ChIJdSWkflu2yhQRBw4n2CqXwfg&fields=name,geometry&key=**************
Result:
{
   "html_attributions" : [],
   "status" : "NOT_FOUND"
}

Happened to me today! Very frustrating! Lost a ton of money!!

Same issue for me.
Steps:
1. Use Autocomplete API to get a list of places.
2. Select Hong Kong (place_id: ChIJD5gyo-3iAzQRfMnq27qzivA) from results
3. Query Places API (details end point with above place_id)
4. Get NOT_FOUND

Full response:
{
   "html_attributions" : [],
   "status" : "NOT_FOUND"
}

Works fine for other places

Same problem with "München, Germany"

https://developers-dot-devsite-v2-prod.appspot.com/maps/documentation/javascript/examples/places-autocomplete-addressform

There is an on-going incident: https://issuetracker.google.com/145144256

Please refrain from posting comments on issues that have been Fixed a long time ago (file a new one instead).