Verified
Status Update
No update yet.
Comments
yb...@google.com
cc...@google.com
A couple of questions:
1. Have you saw crash in real device or only in simulators?
2. Do you use dynamic feature for language ID?
1. Have you saw crash in real device or only in simulators?
2. Do you use dynamic feature for language ID?
cc...@google.com
Tested on Android 12 Emulator with custom executor, but cannot repro this issue.
cc...@google.com
-
Second crash in the description is from a real device. Experienced it myself on two different Xiaomi phones, plus lots of crashes from users in the Google Play console.
-
Dynamic features are not used in the application.
As a wild guess, I have downgraded build tools from 31.0.0 to 30.0.3, compileSdk from 31 to 30, and moved all work with Language ID to the service in a separate process (just to be sure that crash can kill secondary process instead of main). This combination is in beta for 2 days by now and I don't see any SIGSEGV crashes.
Description
Version used: 1.0.0-alpha5
Devices/Android versions reproduced on: n/a
Steps to Reproduce: Attempt to call loadInitial() on a PositionalDataSource
Expected Result: For it to be possible to call loadInitial() on a PositionalDataSource
Actual Result:
- We cannot create instances of PositionalDataSource.LoadInitialCallback, because the LoadInitialCallback constructor takes a PageResult.Receiver<T> parameter, and PageResult is not public
- The LoadInitialCallback constructor is not public or protected, so we cannot chain to the superclass in our own LoadInitialCallback subclasses
- The same two problems hold for LoadRangeCallback (depends on PageResult, constructor not public or protected) for calls to loadRange() on a PositionalDataSource
As it stands, we cannot write code to consume a PositionalDataSource, such as those from Room, because we cannot call loadInitial() or loadRange(), because we cannot provide the necessary callbacks.
Workaround: put classes using PositionalDataSource into android.arch.paging, which is really icky