IssueTracker

since these are in public API (:/) we need to do this in 1.2

Opening diff shortly

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

commit d576cbdc911cba16638a44fd8223391a90a07ef7
Author: Mike Nakhimovich <digitalbuddha@users.noreply.github.com>
Date:   Tue Aug 11 09:30:34 2020

    [GH] Hide deprecated internal API.
   
    ## Proposed Changes
   
    * `RoomDatabase.java` has protected `mCallbacks` field which is leaking in the API docs, we should @Hide it.
   
    ## Testing
   
    Test: Ran unit tests locally
   
    ## Issues Fixed
   
    Fixes: 76109329
   
    This is an imported pull request from https://github.com/androidx/androidx/pull/61.
   
    Resolves #61
    Github-Pr-Head-Sha: 6440daa3a63752c7f9d5ba2a390248cd85bc634f
    GitOrigin-RevId: fe92d8466a59b44b218b6ca3cbd57dcda17992f7
   
    Change-Id: Id599cdf5b02b32bdae0166266fb7da967598fe92

A       room/runtime/api/current.ignore
M       room/runtime/api/current.txt
M       room/runtime/api/public_plus_experimental_current.txt
M       room/runtime/api/restricted_current.txt
M       room/runtime/src/main/java/androidx/room/RoomDatabase.java

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

Unfortunately we do not have enough actionable information to proceed further on this issue. Kindly share the requested details and raise a new bug in case issue is seen in future.

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)

To describe what's happening in the sample, clicking the button adds a chunk of elements to the ListAdapter but also modifies an existing element. The real-world use case is a list of category headers which expand when clicked.  After applying the two changes to the adapter, the DiffUtil is creating two ops of [ADD, UPDATE]. The ADD operation modifies mFullSpanItems.mPosition to be something like [1, 2, 3, 4, 5, 11, 12, 13, 14]. The op also tries to ensure that mData is large enough but instead does nothing. The UPDATE op then does an array copy by utilizing the mPosition values from the previous op. These mPosition values are outside the bounds of the array.

This issue seems relevant but was marked fixed - probably because it's hard to reproduce.

https://issuetracker.google.com/issues/37086625

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

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

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

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