Status Update
Comments
se...@gmail.com <se...@gmail.com> #2
ry...@google.com <ry...@google.com> #3
se...@gmail.com <se...@gmail.com> #4
private void refreshAllLiveData() {
AppDataBase YOUR_DATABASE_WHICH_YOU_BUILD = .....
SupportSQLiteDatabase writableDatabase = YOUR_DATABASE_WHICH_YOU_BUILD.getOpenHelper().getWritableDatabase();
//get the database count;
Cursor cursor = writableDatabase.query("SELECT count(*) FROM sqlite_master WHERE type = 'table' AND name != 'android_metadata' AND name != 'room_master_table';");
int tableCount = 0;
while(cursor.moveToNext()) {
tableCount = cursor.getInt(0);
}
for (int i = 0; i < tableCount; i++) {
//update version table with the incremented count because room modification log stores tables with ids instead of names
writableDatabase.execSQL("INSERT OR REPLACE INTO room_table_modification_log VALUES(null, "+(i)+")");
}
YOUR_DATABASE_WHICH_YOU_BUILD.getInvalidationTracker().refreshVersionsAsync();
}
-----
This is a workaroud for refreshing all live datas, I still prefer to use a proper API you implemented.
Thanx
se...@gmail.com <se...@gmail.com> #5
ry...@google.com <ry...@google.com> #6
Hmmm, that looks like mChildHelper.getChildAt(i)
is probably returning null (either that or the LayoutParams is getting messed up somehow) despite being called with values derived from mChildHelper.getChildCount()
, which shouldn't happen.
That general pattern of the ChildHelper having the wrong state reminds me of
se...@gmail.com <se...@gmail.com> #7
Oh wow, thanks, this is a better lead than anything we have! Any ideas on what we could do to try to force this state/crash? e.g. reinitialize things in the wrong order, use wrong LayoutParams or anything of the sort?
Since we're not able to reproduce, we're trying to see if we can work backwards and then find which UI its crashing for (we have a lot of RecyclerViews in the app alive simultaneously).
ce...@gotinder.com <ce...@gotinder.com> #8
The same is happening to us (using both RV + VP2)
I was about to either open an issue on the tracker or try to add a contribution to AOSP, because after looking at the code, it seems there is a line where RecyclerView should be doing child != null && child.shouldIgnore() but it's not actually checking for nullability (exactly what the Googler on the thread brought up)
See screenshot attached:
> is to get a release containing only that fix out in a few weeks as RecyclerView 1.3.2. If you're feeling especially brave (probably most useful if you manage to reproduce the issue, even inconsistently, and can test to see if it still happens
I tried to reproduce the issue here at Tinder, and I wasn't able to. I created a sample project for it too and there was no way, even using debugging options to re-create the Activity and what not.
I'm happy to contribute to AOSP if we haven't fixed this yet. We are really interested in getting the fix ASAP, so I'm happy to hear feedback and/or actionable steps if necessary.
Thanks in advance!
se...@gmail.com <se...@gmail.com> #9
even using debugging options to re-create the Activity and whatnot.
Exactly. We are theorizing that it might have something to do with corrupted saved instance state/configuration change since we recently enabled dark mode in the app.
Still no repro even with that hypothesis, so any leads on reverse-engineering this crash (or even writing a UI test) would be super helpful.
ry...@google.com <ry...@google.com> #10
Any ideas on what we could do to try to force this state/crash?
The person who figured it out reproduced it by writing a test that submitted large numbers of random operations to the RecyclerView:
se...@gmail.com <se...@gmail.com> #11
writing a test that submitted large numbers of random operations to the RecyclerView
Interesting, is there a publicly accessible link? The one you mentioned appears to be internal to Google. 🙏
ry...@google.com <ry...@google.com> #12
Apologies, I've fixed the link. If we ever mess that up in the future, you can always swap out android-review.git.corp.google.com
for android-review.googlesource.com
to get the public link.
ry...@google.com <ry...@google.com> #13
RecyclerView 1.3.2 and 1.4.0-alpha01 are now released with the fix for
se...@gmail.com <se...@gmail.com> #14
The issue still seems to persist with 1.3.2, although we are seeing slightly different traces at dispatchLayoutStep3()
:
#1
java.lang.NullPointerException: Attempt to invoke virtual method 'boolean androidx.recyclerview.widget.RecyclerView$ViewHolder.shouldIgnore()' on a null object reference
at androidx.recyclerview.widget.RecyclerView.dispatchLayoutStep3(RecyclerView:4671)
at androidx.recyclerview.widget.RecyclerView.dispatchLayout(RecyclerView:4367)
at androidx.recyclerview.widget.RecyclerView.consumePendingUpdateOperations(RecyclerView:2095)
at androidx.recyclerview.widget.RecyclerView$1.run(RecyclerView:468)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:995)
at android.view.Choreographer.doCallbacks(Choreographer.java:817)
at android.view.Choreographer.doFrame(Choreographer.java:744)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:980)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:236)
at android.app.ActivityThread.main(ActivityThread.java:8131)
at java.lang.reflect.Method.invoke(Method.java:-2)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:620)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1011)
#2
java.lang.NullPointerException: Attempt to invoke virtual method 'boolean androidx.recyclerview.widget.RecyclerView$ViewHolder.shouldIgnore()' on a null object reference
at androidx.recyclerview.widget.RecyclerView.dispatchLayoutStep3(RecyclerView:4671)
at androidx.recyclerview.widget.RecyclerView.dispatchLayout(RecyclerView:4367)
at androidx.recyclerview.widget.RecyclerView.onLayout(RecyclerView:4919)
at android.view.View.layout(View.java:24958)
at android.view.ViewGroup.layout(ViewGroup.java:6784)
at androidx.constraintlayout.widget.ConstraintLayout.onLayout(ConstraintLayout:1855)
at android.view.View.layout(View.java:24958)
at android.view.ViewGroup.layout(ViewGroup.java:6784)
at android.widget.LinearLayout.setChildFrame(LinearLayout.java:1829)
at android.widget.LinearLayout.layoutVertical(LinearLayout.java:1673)
at android.widget.LinearLayout.onLayout(LinearLayout.java:1582)
at android.view.View.layout(View.java:24958)
at android.view.ViewGroup.layout(ViewGroup.java:6784)
at android.widget.FrameLayout.layoutChildren(FrameLayout.java:332)
at android.widget.FrameLayout.onLayout(FrameLayout.java:270)
at android.view.View.layout(View.java:24958)
at android.view.ViewGroup.layout(ViewGroup.java:6784)
at androidx.constraintlayout.widget.ConstraintLayout.onLayout(ConstraintLayout:1855)
at android.view.View.layout(View.java:24958)
at android.view.ViewGroup.layout(ViewGroup.java:6784)
at androidx.coordinatorlayout.widget.CoordinatorLayout.layoutChild(CoordinatorLayout:1248)
at androidx.coordinatorlayout.widget.CoordinatorLayout.onLayoutChild(CoordinatorLayout:934)
at androidx.coordinatorlayout.widget.CoordinatorLayout.onLayout(CoordinatorLayout:954)
at android.view.View.layout(View.java:24958)
at android.view.ViewGroup.layout(ViewGroup.java:6784)
at android.widget.FrameLayout.layoutChildren(FrameLayout.java:332)
at android.widget.FrameLayout.onLayout(FrameLayout.java:270)
at android.view.View.layout(View.java:24958)
at android.view.ViewGroup.layout(ViewGroup.java:6784)
Description
Component used:
androidx.recyclerview:recyclerview
Version used:
1.3.1
Devices/Android versions reproduced on: A wide range of devices, mostly on Android 13
The stacktrace has NO actionable information.
So, we have no idea where this crash is even happening, and therefore have not been able to repro. Need help in determining what could cause errors like these so that we can start trying to narrow it down.
Full stacktrace: