IssueTracker

Would you be able to describe your use case of why you need to do on the order of hundreds of directions requests please?

Sure. This is my application: http://lstsim.de/

It is in German, so here's a short description: It's a simulation of an emergency services dispatch center. The user is in charge of sending ambulances to different places all over the area. I'm using the Directions Service, so the ambulances on the map use the actual roads (and even respect the speed limits). Every trip from one location to another takes a single request. This allows me to achieve a pretty realistic replication of the reality.

This also means I don't actually need a routing request every second, but it rather depends on how busy things are in the game. My users were reporting routing errors usually after 300 routings and about an hour or so of playing, so you get an idea of the average request rate.

This problem sounds similar to behavior I am seeing with versions 3.10+ ... my application allows users to create maps of their addresses. After 200 or so rows the geocoder becomes very very slow, even if I delay geocodes 5-10 seconds in-between.

Since the limit is 2500 per day, does it not seem reasonable that you would be able to send a geocode 1 per second as you have in the past until you reach 2500? If this is a change to the quota and limits of the free google maps API please let us know.

Google is forcing 3.10 now so there is no using 3.9 to get around this bug.

I need to know if this is a permanent change on geocoding quotas or if this is truly a bug. If it is a permanent change I will need to make big changes to our app so users can only create maps of 200 or less points, whereas before it was possible to create 2500 marker maps.

Any update on this? Is it a bug or a change?

Would it be possible to reopen this issue? I believe I've found the same thing although in my case the index is off the end of the array.  I've created a sample application which reproduces the issue:

https://drive.google.com/file/d/1AB-Gl_hfkO9SBTYIiLJ1tMjQcMeB7ttl/view?usp=sharing

NOTE: The device resolution is important because the number of elements visible and the number of elements added to the RecyclerView is specific.  Please run this on an emulator of 1080x1920 (confirmed on Pixel API 27 and Nexus 5 API 25).

Repro steps:
1. Create an emulator with 1080x1920.
2. Launch the StaggeredBug sample on the emulator.
3. Click the button at the bottom of the view.

Callstack:
java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 13
        at java.util.Arrays.rangeCheck(Arrays.java:1598)
        at java.util.Arrays.fill(Arrays.java:2928)
        at androidx.recyclerview.widget.StaggeredGridLayoutManager$LazySpanLookup.invalidateAfter(StaggeredGridLayoutManager.java:2878)
        at androidx.recyclerview.widget.StaggeredGridLayoutManager.handleUpdate(StaggeredGridLayoutManager.java:1550)
        at androidx.recyclerview.widget.StaggeredGridLayoutManager.onItemsUpdated(StaggeredGridLayoutManager.java:1526)
        at androidx.recyclerview.widget.RecyclerView$6.dispatchUpdate(RecyclerView.java:1016)
        at androidx.recyclerview.widget.RecyclerView$6.onDispatchSecondPass(RecyclerView.java:1027)
        at androidx.recyclerview.widget.AdapterHelper.consumePostponedUpdates(AdapterHelper.java:121)
        at androidx.recyclerview.widget.AdapterHelper.consumeUpdatesInOnePass(AdapterHelper.java:557)
        at androidx.recyclerview.widget.RecyclerView.dispatchLayoutStep2(RecyclerView.java:3918)
        at androidx.recyclerview.widget.RecyclerView.dispatchLayout(RecyclerView.java:3641)
        at androidx.recyclerview.widget.RecyclerView.onLayout(RecyclerView.java:4194)
        at android.view.View.layout(View.java:17637)
        at android.view.ViewGroup.layout(ViewGroup.java:5575)
        at android.widget.LinearLayout.setChildFrame(LinearLayout.java:1741)
        at android.widget.LinearLayout.layoutVertical(LinearLayout.java:1585)
        at android.widget.LinearLayout.onLayout(LinearLayout.java:1494)
        at android.view.View.layout(View.java:17637)
        at android.view.ViewGroup.layout(ViewGroup.java:5575)
        at android.widget.FrameLayout.layoutChildren(FrameLayout.java:323)
        at android.widget.FrameLayout.onLayout(FrameLayout.java:261)
        at android.view.View.layout(View.java:17637)
        at android.view.ViewGroup.layout(ViewGroup.java:5575)
        at androidx.appcompat.widget.ActionBarOverlayLayout.onLayout(ActionBarOverlayLayout.java:444)
        at android.view.View.layout(View.java:17637)
        at android.view.ViewGroup.layout(ViewGroup.java:5575)
        at android.widget.FrameLayout.layoutChildren(FrameLayout.java:323)
        at android.widget.FrameLayout.onLayout(FrameLayout.java:261)
        at android.view.View.layout(View.java:17637)
        at android.view.ViewGroup.layout(ViewGroup.java:5575)
        at android.widget.LinearLayout.setChildFrame(LinearLayout.java:1741)
        at android.widget.LinearLayout.layoutVertical(LinearLayout.java:1585)
        at android.widget.LinearLayout.onLayout(LinearLayout.java:1494)
        at android.view.View.layout(View.java:17637)
        at android.view.ViewGroup.layout(ViewGroup.java:5575)
        at android.widget.FrameLayout.layoutChildren(FrameLayout.java:323)
        at android.widget.FrameLayout.onLayout(FrameLayout.java:261)
        at com.android.internal.policy.DecorView.onLayout(DecorView.java:726)
        at android.view.View.layout(View.java:17637)
        at android.view.ViewGroup.layout(ViewGroup.java:5575)
        at android.view.ViewRootImpl.performLayout(ViewRootImpl.java:2346)
        at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:2068)
        at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1254)
        at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:6337)
        at android.view.Choreographer$CallbackRecord.run(Choreographer.java:874)
        at android.view.Choreographer.doCallbacks(Choreographer.java:686)
        at android.view.Choreographer.doFrame(Choreographer.java:621)
        at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:860)
        at android.os.Handler.handleCallback(Handler.java:751)
        at android.os.Handler.dispatchMessage(Handler.java:95)
        at android.os.Looper.loop(Looper.java:154)
        at android.app.ActivityThread.main(ActivityThread.java:6119)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:886)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:776)
Application terminated.

It seems like the call to ensureSize(positionStart + itemCount) in offsetForAddition isn't correct; maybe something like ensureSize(mFullSpanItems.size() + itemCount)?

Thanks,
Tim

https://drive.google.com/file/d/1AB-Gl_hfkO9SBTYIiLJ1tMjQcMeB7ttl/view?usp=drive_web (StaggeredBug.tgz)

An update on this would be greatly appreciated by our users.  Thank you.

Any updates on this issue? When will this bug be fixed.

Any updates about this defect?

Project: platform/frameworks/support
Branch: androidx-master-dev

commit 49b601979ebccb8fcc6b8d670b79ae1c5f818dbf
Author: Kolin Krewinkel <kkrewink@fb.com>
Date:   Mon Jun 29 19:47:11 2020

    [StaggeredGridLayoutManager] Avoid OutOfBounds exception during mutations if SpanLookup data structure has not yet been lengthened
   
    **Background**
    A use case within our app ran into this issue frequently as a result of inserting items between a set of full span items. We applied numerous band-aids (clearing of the span cache, filler items, etc.), but those had a bunch of unintended side-effects.
    - Within the code, my first approach was to limit the array fill to `MIN(length, position)`, but that really didn't feel like the right fix.
    - Digging deeper, I found that the position being extended to with `ensureSize()` did not factor in the maximum extent of items in `mData` or `mFullSpanItems` (which do not necessarily have the same "cap" in terms of position / length).
      - A fix that I tried relating to this was to always `ensureSize()` for mData's length, but that results in expontential growth because of the fact that mData's length ≠ number of items.
    - To keep it simple, I realized the easiest thing to do is just ensure that mData is large enough for the `item count` we're supposed to be displaying.
    - Through discussion in review, we ended up reverting to the simpler version using `MIN()`.
   
    Note that the test case does something which I *think* is pretty uncommon in vanilla adapters, but is the case for us when using it paired with Litho. That was the easiest repro case for me to arrive at, but I'm sure there are others.
   
    Bug:122303625
    Bug:74877618
    Bug:160193663
    Bug:37086625
   
    Test: New test case in StaggeredGridLayoutManagerTest validates that the `Arrays.fill()` invocation does not lead to a crash.
   
    Change-Id: Iab0a1220b4eae8f2b184822d518c6d696c278b19

M       recyclerview/recyclerview/src/androidTest/java/androidx/recyclerview/widget/StaggeredGridLayoutManagerTest.java
M       recyclerview/recyclerview/src/main/java/androidx/recyclerview/widget/StaggeredGridLayoutManager.java

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

So, it's about one year after my last question about the actual status of this defect. Are there any updates?

So, it's about one year after my last question about the actual status of this defect. Are there any updates?