Status Update
No update yet.
Comments
nj...@google.com
1. Have you saw crash in real device or only in simulators?
2. Do you use dynamic feature for language ID?
an...@google.com
Tested on Android 12 Emulator with custom executor, but cannot repro this issue.
an...@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.
nj...@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.
nj...@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)
an...@google.com
FYI, ML Kit launched a new language ID SDK in the latest release, which uses a new language ID model.
Could you try the new SDK version(17.0.0) to check if you can still repro this native crash? Thanks!
nj...@google.com
Thank you, I'll try it and check.
an...@google.com
Hello. I have similar experience.
- I'm using mlkit-language 16.1.1
- I didnot meet this error until using AGP 4.2
- I can get this error since using AGP 7.0
- This error raised on Release build only(minimized by R8)
- This error raised without obfuscation.
an...@google.com
I created reproducible project.
$ git clone https://github.com/ganadist/VersionCodeDemo -b mlkit_agp7 mlkit_agp7
$ cd mlkit_agp7
$ ./gradlew :app:pPRUA
$ adb install app/build/outputs/universal_apk/productionRelease/app-production-release-universal.apk
$ adb shell am start -n com.example.myapplication/.MainActivity
$ adb logcat -b crash -d
10-19 19:41:49.844 17810 17810 F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7acf9d733c in tid 17810 (e.myapplication), pid 17810 (e.myapplication)
10-19 19:41:50.473 17849 17849 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
10-19 19:41:50.473 17849 17849 F DEBUG : Build fingerprint: 'google/crosshatch/crosshatch:12/SPB5.210812.002/7671067:user/release-keys'
10-19 19:41:50.473 17849 17849 F DEBUG : Revision: 'MP1.0'
10-19 19:41:50.473 17849 17849 F DEBUG : ABI: 'arm64'
10-19 19:41:50.473 17849 17849 F DEBUG : Timestamp: 2021-10-19 19:41:49.903736988+0900
10-19 19:41:50.473 17849 17849 F DEBUG : Process uptime: 0s
10-19 19:41:50.473 17849 17849 F DEBUG : Cmdline: com.example.myapplication
10-19 19:41:50.474 17849 17849 F DEBUG : pid: 17810, tid: 17810, name: e.myapplication >>> com.example.myapplication <<<
10-19 19:41:50.474 17849 17849 F DEBUG : uid: 10240
10-19 19:41:50.474 17849 17849 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7acf9d733c
10-19 19:41:50.474 17849 17849 F DEBUG : x0 0000000000000000 x1 00000000000008fc x2 0000007a76760c71 x3 0000000000000000
10-19 19:41:50.474 17849 17849 F DEBUG : x4 0000000000000010 x5 0000007ba4db49d0 x6 0000007b34dc3680 x7 3de38e3900000608
10-19 19:41:50.474 17849 17849 F DEBUG : x8 0000007bb4dbedf0 x9 0000007acf9db2aa x10 0000000000000000 x11 0000007acf9d6640
10-19 19:41:50.474 17849 17849 F DEBUG : x12 0000000000000009 x13 0000000000000000 x14 0000000000000061 x15 00000000ebad6a89
10-19 19:41:50.474 17849 17849 F DEBUG : x16 0000007a767cfef8 x17 0000007d9a564b40 x18 0000007da3830000 x19 0000007feaf56a08
10-19 19:41:50.474 17849 17849 F DEBUG : x20 0000000000000000 x21 0000007ba4da50b0 x22 0000007bb4dbedf0 x23 0000007ba4da50b8
10-19 19:41:50.474 17849 17849 F DEBUG : x24 0000000000000009 x25 000000000000067e x26 0000000000000012 x27 0000000000000008
10-19 19:41:50.474 17849 17849 F DEBUG : x28 0000007b64dc8440 x29 0000000000000000
10-19 19:41:50.474 17849 17849 F DEBUG : lr 0000007a7678a964 sp 0000007feaf56810 pc 0000007a7678b7c0 pst 0000000060000000
10-19 19:41:50.474 17849 17849 F DEBUG : backtrace:
10-19 19:41:50.474 17849 17849 F DEBUG : #00 pc 000000000003c7c0 /data/app/~~mHaMq-e9ocbm9UfYnkCGkQ==/com.example.myapplication-HgG9vkluwDDO1K78-Vzr0A==/lib/arm64/liblanguage_id_jni.so (BuildId: 859ec0ec2000a39e6ae8ed42e1704f46)
10-19 19:41:50.474 17849 17849 F DEBUG : #01 pc 000000000003b960 /data/app/~~mHaMq-e9ocbm9UfYnkCGkQ==/com.example.myapplication-HgG9vkluwDDO1K78-Vzr0A==/lib/arm64/liblanguage_id_jni.so (BuildId: 859ec0ec2000a39e6ae8ed42e1704f46)
10-19 19:41:50.474 17849 17849 F DEBUG : #02 pc 000000000003bb48 /data/app/~~mHaMq-e9ocbm9UfYnkCGkQ==/com.example.myapplication-HgG9vkluwDDO1K78-Vzr0A==/lib/arm64/liblanguage_id_jni.so (BuildId: 859ec0ec2000a39e6ae8ed42e1704f46)
10-19 19:41:50.474 17849 17849 F DEBUG : #03 pc 000000000003bafc /data/app/~~mHaMq-e9ocbm9UfYnkCGkQ==/com.example.myapplication-HgG9vkluwDDO1K78-Vzr0A==/lib/arm64/liblanguage_id_jni.so (BuildId: 859ec0ec2000a39e6ae8ed42e1704f46)
10-19 19:41:50.474 17849 17849 F DEBUG : #04 pc 0000000000036c98 /data/app/~~mHaMq-e9ocbm9UfYnkCGkQ==/com.example.myapplication-HgG9vkluwDDO1K78-Vzr0A==/lib/arm64/liblanguage_id_jni.so (BuildId: 859ec0ec2000a39e6ae8ed42e1704f46)
10-19 19:41:50.474 17849 17849 F DEBUG : #05 pc 00000000000324a4 /data/app/~~mHaMq-e9ocbm9UfYnkCGkQ==/com.example.myapplication-HgG9vkluwDDO1K78-Vzr0A==/lib/arm64/liblanguage_id_jni.so (BuildId: 859ec0ec2000a39e6ae8ed42e1704f46)
10-19 19:41:50.474 17849 17849 F DEBUG : #06 pc 0000000000031b5c /data/app/~~mHaMq-e9ocbm9UfYnkCGkQ==/com.example.myapplication-HgG9vkluwDDO1K78-Vzr0A==/lib/arm64/liblanguage_id_jni.so (Java_com_google_mlkit_nl_languageid_internal_LanguageIdentificationJni_nativeIdentifyLanguage+100) (BuildId: 859ec0ec2000a39e6ae8ed42e1704f46)
But after downgrade to AGP 4.2, crash is not reproducible.
$ git clone https://github.com/ganadist/VersionCodeDemo -b mlkit_agp42 mlkit_agp42
$ cd mlkit_agp42
$ ./gradlew :app:pPRUA
$ adb install app/build/outputs/universal_apk/productionRelease/app-production-release-universal.apk
$ adb shell am start -n com.example.myapplication/.MainActivity
Also, I tried to disable
$ git clone https://github.com/ganadist/VersionCodeDemo -b mlkit_agp7_r8_disable_inline_optimizer mlkit_agp7_r8
$ cd mlkit_agp7_r8
$ ./gradlew :app:pPRUA
$ adb install app/build/outputs/universal_apk/productionRelease/app-production-release-universal.apk
$ adb shell am start -n com.example.myapplication/.MainActivity
nj...@google.com
I tried the repro steps but got a NPE when I run ./gradlew :app:pPRUA
FAILURE: Build failed with an exception.
* What went wrong:
java.lang.NullPointerException
> java.lang.NullPointerException (no error message)
Could you also check if this is reproducible on 17.0.0 or 17.0.1? If yes, could you attach the full log that I can take a look? Thanks!
an...@google.com
Here are gradle build scan logs for each branches.
All builds were clean build, and disabled build cache.
- mlkit_agp7 :
https://scans.gradle.com/s/qrymdqfzwokbq - mlkit_agp42 :
https://scans.gradle.com/s/b6644hzfyfhaw - mlkit_agp7_r8_disable_inline_optimizer :
https://scans.gradle.com/s/c6h5hy2nxod4u
Also, I pushed to update MLKit Language Id version 17.0.1 on
And here is crash log after apply 17.0.1
You can see that BuildId of liblanguage_id_l2c_jni.so was changed from 859ec0ec2000a39e6ae8ed42e1704f46 to be6e59455cc10135330c93acdebfc121
10-20 03:07:24.522 24587 24628 F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7acf995426 in tid 24628 (pool-3-thread-3), pid 24587 (e.myapplication)
10-20 03:07:25.190 24710 24710 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
10-20 03:07:25.190 24710 24710 F DEBUG : Build fingerprint: 'google/crosshatch/crosshatch:12/SPB5.210812.002/7671067:user/release-keys'
10-20 03:07:25.190 24710 24710 F DEBUG : Revision: 'MP1.0'
10-20 03:07:25.190 24710 24710 F DEBUG : ABI: 'arm64'
10-20 03:07:25.190 24710 24710 F DEBUG : Timestamp: 2021-10-20 03:07:24.583346246+0900
10-20 03:07:25.190 24710 24710 F DEBUG : Process uptime: 0s
10-20 03:07:25.190 24710 24710 F DEBUG : Cmdline: com.example.myapplication
10-20 03:07:25.190 24710 24710 F DEBUG : pid: 24587, tid: 24628, name: pool-3-thread-3 >>> com.example.myapplication <<<
10-20 03:07:25.190 24710 24710 F DEBUG : uid: 10240
10-20 03:07:25.190 24710 24710 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7acf995426
10-20 03:07:25.190 24710 24710 F DEBUG : x0 0000007b54da9d30 x1 0000007d9a5fe7cc x2 0000000000000000 x3 0000000000000010
10-20 03:07:25.190 24710 24710 F DEBUG : x4 0000000000000000 x5 0000007c34dbc79c x6 0000002f0000083b x7 000003c300002dd5
10-20 03:07:25.190 24710 24710 F DEBUG : x8 0000000000000001 x9 0000000000000004 x10 0000000000000010 x11 0000000000000000
10-20 03:07:25.190 24710 24710 F DEBUG : x12 0000000000000000 x13 000000000000217e x14 0000007acf9932a8 x15 000000000000217e
10-20 03:07:25.190 24710 24710 F DEBUG : x16 0000000000000000 x17 0000007d9a564c78 x18 0000007a6ef18000 x19 0000007c34dbc580
10-20 03:07:25.190 24710 24710 F DEBUG : x20 0000007ca4dc7170 x21 0000007ca4dc7800 x22 0000007ca4dc71e0 x23 0000000000000000
10-20 03:07:25.190 24710 24710 F DEBUG : x24 0000000000000018 x25 0000000000000007 x26 0000000000000006 x27 0000000000000004
10-20 03:07:25.190 24710 24710 F DEBUG : x28 0000007ca4dc7090 x29 0000007cb4da9940
10-20 03:07:25.190 24710 24710 F DEBUG : lr 0000007a770a9624 sp 0000007a6f7de9c0 pc 0000007a770a96a8 pst 0000000020000000
10-20 03:07:25.190 24710 24710 F DEBUG : backtrace:
10-20 03:07:25.190 24710 24710 F DEBUG : #00 pc 00000000000386a8 /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG : #01 pc 00000000000388a0 /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG : #02 pc 00000000000844a0 /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG : #03 pc 000000000008783c /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG : #04 pc 0000000000035fc4 /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG : #05 pc 0000000000034954 /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.190 24710 24710 F DEBUG : #06 pc 00000000000340e8 /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/lib/arm64/liblanguage_id_l2c_jni.so (Java_com_google_mlkit_nl_languageid_internal_ThickLanguageIdentifier_nativeIdentifyPossibleLanguages+108) (BuildId: be6e59455cc10135330c93acdebfc121)
10-20 03:07:25.191 24710 24710 F DEBUG : #07 pc 00000000002d9a44 /apex/com.android.art/lib64/libart.so (art_quick_generic_jni_trampoline+148) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG : #08 pc 000000000020a700 /apex/com.android.art/lib64/libart.so (nterp_helper+5648) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG : #09 pc 00000000000cd0dc /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG : #10 pc 000000000020a044 /apex/com.android.art/lib64/libart.so (nterp_helper+3924) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG : #11 pc 00000000000ccfa8 /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG : #12 pc 0000000000557cb4 /system/framework/arm64/boot-framework.oat (android.os.Binder.transact+148) (BuildId: 43a571a0ad85d6451b47016336a541ecb0eb12bb)
10-20 03:07:25.191 24710 24710 F DEBUG : #13 pc 000000000020b53c /apex/com.android.art/lib64/libart.so (nterp_helper+9292) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG : #14 pc 00000000000b7aba /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG : #15 pc 000000000020a044 /apex/com.android.art/lib64/libart.so (nterp_helper+3924) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG : #16 pc 00000000000a7496 /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG : #17 pc 000000000020a044 /apex/com.android.art/lib64/libart.so (nterp_helper+3924) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG : #18 pc 00000000000a7360 /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG : #19 pc 000000000020ae64 /apex/com.android.art/lib64/libart.so (nterp_helper+7540) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG : #20 pc 000000000009e46c /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG : #21 pc 000000000020ae64 /apex/com.android.art/lib64/libart.so (nterp_helper+7540) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG : #22 pc 00000000000d33d6 /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG : #23 pc 000000000020ae64 /apex/com.android.art/lib64/libart.so (nterp_helper+7540) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG : #24 pc 000000000009df0a /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG : #25 pc 0000000000209124 /apex/com.android.art/lib64/libart.so (nterp_helper+52) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG : #26 pc 000000000009e350 /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG : #27 pc 000000000037b9ac /apex/com.android.art/javalib/arm64/boot.oat (java.util.concurrent.ThreadPoolExecutor.runWorker+988) (BuildId: ab2bf4ec264efdb6c452a238be38fe624de826b8)
10-20 03:07:25.191 24710 24710 F DEBUG : #28 pc 00000000003751d4 /apex/com.android.art/javalib/arm64/boot.oat (java.util.concurrent.ThreadPoolExecutor$Worker.run+68) (BuildId: ab2bf4ec264efdb6c452a238be38fe624de826b8)
10-20 03:07:25.191 24710 24710 F DEBUG : #29 pc 000000000020aec4 /apex/com.android.art/lib64/libart.so (nterp_helper+7636) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG : #30 pc 000000000009e370 /data/app/~~KjjULZV48O7KSOgOP1wYNQ==/com.example.myapplication-vFUidUPTjaGg4oo3SRAYJw==/oat/arm64/base.vdex
10-20 03:07:25.191 24710 24710 F DEBUG : #31 pc 00000000001bf35c /apex/com.android.art/javalib/arm64/boot.oat (java.lang.Thread.run+76) (BuildId: ab2bf4ec264efdb6c452a238be38fe624de826b8)
10-20 03:07:25.191 24710 24710 F DEBUG : #32 pc 00000000002d0164 /apex/com.android.art/lib64/libart.so (art_quick_invoke_stub+548) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG : #33 pc 000000000031ccac /apex/com.android.art/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+156) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG : #34 pc 00000000003cf8a0 /apex/com.android.art/lib64/libart.so (art::JValue art::InvokeVirtualOrInterfaceWithJValues<art::ArtMethod*>(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, art::ArtMethod*, jvalue const*)+380) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG : #35 pc 0000000000460894 /apex/com.android.art/lib64/libart.so (art::Thread::CreateCallback(void*)+992) (BuildId: cdecb8dde1264c9871695c29854aa3b1)
10-20 03:07:25.191 24710 24710 F DEBUG : #36 pc 00000000000b1910 /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+264) (BuildId: ba489d4985c0cf173209da67405662f9)
10-20 03:07:25.191 24710 24710 F DEBUG : #37 pc 00000000000513f0 /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: ba489d4985c0cf173209da67405662f9)
nj...@google.com
Cross-posted on R8 issue tracker.
an...@google.com
Hi,
Looks like we figured out the root cause in
For temporary workarounds for the existing SDKs, you need to add this rule
-keep class com.google.mlkit.nl.languageid.internal.LanguageIdentificationJni { *; }
for language-id 16.1.1, and add this rule
-keep class com.google.mlkit.nl.languageid.internal.ThickLanguageIdentifier { *; }
for version language-id 17.0.0+ for the newer model.
We'll fix this issue in the upcoming release so that you'll not need these workarounds in the future release.
Thanks a lot for reporting this issue!
nj...@google.com
Added workarounds in
an...@google.com
nj...@google.com
It is up to the developer use case. If they are never translating the child composable after the fact, then this implementation is fine as is. However, if they intend on animating it afterwards then we should be pointing them to use Modifier.translate instead.
mo...@google.com
I added Matvei because I think he preferred opacity over alpha.
We can't remove offset/offsetPx as they are now as they are layout parameters and don't require a layer. I don't think we want to be adding layers for each offset, do we?
I think it is fine to have separate modifiers for rotation and scaling. We may even prefer to make only the simple versions (rotationZ and scaleX = scaleY) and require developers to use the graphicsLayer modifier for the fancier versions. They are convenience methods, after all, and only 1 liners.
I don't see any benefit from adding a translation modifier. I doubt it will be common use and, again, a two-liner if the developer makes it themselves. Most commonly, the developer will use offset + graphicsLayer to achieve the same thing.
nj...@google.com
We still need translation to do efficient movement/scrolling of children within a container. Additionally it is useful for modifying a composable in response to touch gestures (drag and drop). Using offset for these requires layout + measurement passes instead of just an efficient invalidation call (draw commands are not re-recorded).
I do like the 1 liners however, I am concerned that it forces developers to think of order of operations for multiple transformations which may introduce additional/unnecessary layers as a result. But generally speaking keeping the names consistent with the fields (i.e. using alpha vs opacity) is clearer.
nj...@google.com
Another thing to consider is how Modifier.offset is consumed within a composable container. For example we could have a FlexLayout composable that will always attempt to layout children from left to right until the available width is consumed. Then subsequent children will be positioned below the previous ones. I believe it would make sense for offset to contribute to the "reflowing" of content to the next line. However, if we wanted to translate content to be drawn on top and not contribute to reflowing of content (ex. for a drag and drop UI or text marquee) we would need to leverage translation here. While offset and translate are similar to do serve different use cases.
mo...@google.com
offset should not affect the measure pass, but it will have to rerun placement.
With respect to alpha/opacity, these terms may both be consistent, but with different surfaces. It may be that Material Design specifies "opacity," while the graphics engine specifies "alpha." I think that in this case, we should choose whichever is more familiar to the application developer.
nj...@google.com
offset should not affect the measure pass, but it will have to rerun placement.
The contents will measure the same way however in the FlexLayout example, an offset modifier placed on a single child will affect the layout placement of the other siblings in the composable container.
I think that in this case, we should choose whichever is more familiar to the application developer.
Should we stick to alpha to be consistent with View.setAlpha? We only used opacity within the Drawable#getOpacity API which used to be a hint for an internal optimization in the framework that is no longer done anymore.
mo...@google.com
Offset does not affect the placement of other siblings. It simply offsets the child.
The language around opacity may come from the Material spec. I am unsure and want Matvei's input here.
an...@google.com
ma...@google.com
Hello! I used to prefer opacity since you are modifying the opacity of the component, not the "alpha channel". As far as I'm aware, material also prefers opacity, but since the API we're making here are not purely material, this is not super relevant I'd say.
Overall for me it's 60/40 preference for opacity over alpha. Also plus for opacity is that it's already familiar to compose devs. I will leave this decision up to you folks since I would be happy to have any of whose, especially without draw prefix :)
nj...@google.com
Layer is a design language agnostic API so I am not sure we should be leveraging material naming conventions here. Different design languages (holo, material, etc.) should be built on the foundation building blocks rather than building the foundation on design naming conventions. If we need to the material lib could have a typealias for Modifier.opacity that maps to alpha if we need to keep naming consistency. Also if we are helping to onboard traditional android framework developers keeping alpha here would help for discoverability.
For simplicity I'm thinking maybe we could just have the simplest shadow, alpha, scale and rotate APIs without including pivot point. I am still concerned with extraneous layer calls because it is more likely to do Modifier.scale(2f).rotate(45) than to do Modifier.drawLayer{ /* block */}.drawLayer{/* block */}. The overhead of this API surface scales worse as additional transformations are added on.
That being said, what about the following convenience APIs?
Modifier.shadow(elevation: Dp, shape: Shape, clip: Boolean) // same as Modifier.drawShadow just drop the draw prefix
Modifier.alpha(alpha: Float)
Modifier.rotate(degrees: Float) // (aka rotateZ) rotates about the center of the composable
Modifier.scale(scaleX: Float, scaleY: Float) // scales the horizontal/vertical dimensions about the center of the composable
Modifier.scale(scale: Float) // same as above except scales both horizontal and vertical by the same scale factor
All other use cases we can point the developer to use the Modifier.drawLayer API to rotateX/Y, rotate with a different pivot point, translate, configure camera distance, etc.
Thoughts?
al...@gmail.com
Hehe... naming is always so complicated. :)
My 2 cents... I'm kind of fine with either "alpha" or "opacity" TBH. On one hand, "alpha" is nice because it's similar to what already exists in Android with View#setAlpha(). On the other hand, opacity is not difficult to understand (and is even used in SVG to apply opacity to nodes in the same way you apply alpha to Views on Android).
I tend to agree with you all that the 'draw' prefix is not necessary and goes against the conventions of other similar APIs.
an...@google.com
ap...@google.com
Branch: androidx-master-dev
commit b89a33a434327022fb96fa4479686fe4cd826f48
Author: Nader Jawad <njawad@google.com>
Date: Thu Nov 19 18:44:23 2020
Added convenience APIs for layer transforms
Relnote: "Added Modifier.scale/rotate
APIs as conveniences for drawLayer.
--Renamed Modifier.drawOpacity to Modifier.alpha
--Renamed Modifier.drawShadow to Modifier.shadow"
Fixes: 173208140
Test: Added tests to DrawLayerTest
Change-Id: I264ca72b36ea62fd615436849203895ed742fa1e
M compose/animation/animation/samples/src/main/java/androidx/compose/animation/samples/AnimatedValueSamples.kt
M compose/animation/animation/src/commonMain/kotlin/androidx/compose/animation/Crossfade.kt
M compose/material/material/integration-tests/material-demos/src/main/java/androidx/compose/material/demos/ColorPickerDemo.kt
M compose/material/material/src/androidAndroidTest/kotlin/androidx/compose/material/BottomSheetScaffoldTest.kt
M compose/material/material/src/androidAndroidTest/kotlin/androidx/compose/material/ScaffoldTest.kt
M compose/material/material/src/commonMain/kotlin/androidx/compose/material/BottomNavigation.kt
M compose/material/material/src/commonMain/kotlin/androidx/compose/material/TextFieldImpl.kt
M compose/ui/ui/api/current.txt
M compose/ui/ui/api/public_plus_experimental_current.txt
M compose/ui/ui/api/restricted_current.txt
M compose/ui/ui/samples/src/main/java/androidx/compose/ui/samples/AlphaSample.kt
M compose/ui/ui/samples/src/main/java/androidx/compose/ui/samples/RotateSample.kt
M compose/ui/ui/samples/src/main/java/androidx/compose/ui/samples/ScaleSample.kt
M compose/ui/ui/samples/src/main/java/androidx/compose/ui/samples/ShadowSample.kt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/draw/AlphaTest.kt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/draw/DrawLayerTest.kt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/draw/ShadowTest.kt
A compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/draw/Alpha.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/draw/Rotate.kt
A compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/draw/Scale.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/draw/Shadow.kt
Description
For example when user wants to add a shadow they will probably write Modifier.shadow. Our overload currently called Modifier.drawShadow(). Should we get rid from "draw" here? I think yes.
The same is true for Modifier.drawOpacity(). But here it is even more interesting. Do people think about that as opacity or alpha? In Views we had setAlpha. Should we rename it to Modifier.alpha() instead?
Modifier.clip() already has no "draw" in its name.
On a related note I think we should also provide Modifier.rotation() and Modifier.scale(), I saw people asking on how to do rotation in Compose in kotlinslack more then once. I suggest to not add Modifier.translation() though as I already mention in the doc recently it would be impossible to understand when to use Modifier.offsetPx() and when Modifier.translation().
Wdyf?