Status Update
No update yet.
Comments
yb...@google.com
1. Have you saw crash in real device or only in simulators?
2. Do you use dynamic feature for language ID?
ro...@gmail.com
Tested on Android 12 Emulator with custom executor, but cannot repro this issue.
ro...@gmail.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.
yb...@google.com
Hmm, I feel the crash might be something related to separate/secondary process.
I also changed compileSdk and targetSDK to 31 but still cannot repro this issue.
yb...@google.com
On the contrary, there was no separate process before, when crashes started.
In the new build (with the aforementioned changes) I can see SIGSEGV crash, but only one instead of dozens and it has a bit different backtrace:
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)
liblanguage_id_jni.so (offset 0x11e000)
backtrace:
#00 pc 000000000003c7c0 /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
#00 pc 000000000003b960 /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
#00 pc 000000000003bb48 /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
#00 pc 000000000003bafc /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
#00 pc 0000000000036c98 /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
#00 pc 0000000000032714 /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
#00 pc 0000000000031cac /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
#00 pc 0000000000057438 /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/oat/arm64/base.odex (offset 0x57000)
Description
Version used:
Devices/Android versions reproduced on: Android API 26
- Sample project is here:
- Kotlin annotation processor throws this error: "e: [kapt] An exception occurred: java.lang.IllegalArgumentException: ? extends com.codepath.apps.restclienttemplate.models.Tweetcannot be converted to an Element".
The particular line in question is here:
@Query("SELECT * FROM User WHERE userId = :id")
UserTweetsFail byId(long id); // change to UserTweetsWorks to see this pass
Where UserTweetsFail.kt is:
class UserTweetsFail {
@Embedded var user: User? = null
@Relation(parentColumn = "userId", entityColumn = "id", entity=Tweet::class)
var tweets: List<Tweet> = listOf()
}
If I change to use UserTweetWorks to use the Java version
UserTweetWorks.java:
public class UserTweetsWorks {
@Embedded
User user;
@Relation(parentColumn = "userId", entityColumn = "id", entity=Tweet.class)
List<Tweet> tweets;
}
The difference seems to be that a Kotlin collection of tweets is essentially:
@Relation(parentColumn = "userId", entityColumn = "id", entity=Tweet.class)
List<? extends Tweet> tweets;
This seems to break the Auto library, since the list is now a subtype of Tweet.
I'm confused why this didn't show up in the integration tests in AOSP -- there seems to be an exact class (