Fixed
Status Update
No update yet.
Comments
ar...@gmail.com
since these are in public API (:/) we need to do this in 1.2
ar...@gmail.com
since it is already marked as deprecated, we can probably do it by now.
am...@google.com
ar...@gmail.com
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 fromhttps://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
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
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
am...@google.com
Could you please provide more clarity on expected and observed behavior along with the screenshots.
Let me know how to use your app to reproduce the issue
Also check it once with the latest support lib 24.2.1 and let me know if issue persists
Let me know how to use your app to reproduce the issue
Also check it once with the latest support lib 24.2.1 and let me know if issue persists
ar...@gmail.com
With latest support lib (25.0.0), the problem did not appear any more. Also with previous (24.2.1). Thanky you.
am...@google.com
Thanks for the update.
co...@gmail.com
ap...@google.com
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
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
ap...@google.com
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
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
ap...@google.com
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
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
ap...@google.com
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
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
Description
I'm doing this the first time, so please have merci ;)
I am using a StaggeredGridLayoutManager in my RecyclerView inside of a Fragment.
While performing a search over a list the vizualisation works as it should and items are getting removed and added.
But after filtering all elements of the list out so the view is empty and then removing the additional letter so the previous items should be seeable again, an ArrayIndexOutOfBoundsException is thrown at java.util.Arrays.checkStartAndEnd(Arrays.java:1732) with the message "start < 0 || end > len. start=-1, end=11, len=11".
I added the output of "adb bugreport" and added also the main folder of my project, so you can hopefully understand what I am talking about and reporoduce the error.
The Exception is happening on all devices I could use to test, inclusive the emulator (I only had Devices with API lvl 22 & 23).
If you need any further informations I will provide them.
Also I hope that this is a real Bug and not caused by my own stupidity.
Yours sincerely,
David Artmann