Fixed
Status Update
No update yet.
Comments
uc...@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?
je...@google.com
Tested on Android 12 Emulator with custom executor, but cannot repro this issue.
to...@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.
to...@gmail.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.
hu...@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)
hu...@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!
to...@gmail.com
Thank you, I'll try it and check.
hu...@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.
to...@gmail.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
hu...@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!
hu...@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)
to...@gmail.com
Cross-posted on R8 issue tracker.
hu...@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!
to...@gmail.com
Added workarounds in
hu...@google.com
to...@gmail.com
I created new logs without modifying BuildConfig class.
Here is also scan results
https://scans.gradle.com/s/yvff3yytuus2g - build without any change
https://scans.gradle.com/s/kybqkbt5xvzms/ - build with one modified method
Without --info and --scan it takes 30s without change and something like 1 minute with one change.
Also configuration phase is very slow :-(, but this is different topic.
Here is also scan results
Without --info and --scan it takes 30s without change and something like 1 minute with one change.
Also configuration phase is very slow :-(, but this is different topic.
hu...@google.com
Configuration time will get better in upcoming versions of the Android Gradle plugin, based on the idea of task configuration avoidance: https://docs.gradle.org/current/userguide/task_configuration_avoidance.html . (If you want, you can create a new bug, let me know the bug number, and I will keep you updated on that bug when there is progress in this area.)
For this bug, let's focus on making your Java compilation task incremental. With the change above, I see this line:
"Full recompilation is required because 'DashboardActivity.java' was changed. Analysis took 0.867 secs."
Can you describe what the change was? (For future experiments, please describe the change + send me the log + build scan. Thanks!)
For this bug, let's focus on making your Java compilation task incremental. With the change above, I see this line:
"Full recompilation is required because 'DashboardActivity.java' was changed. Analysis took 0.867 secs."
Can you describe what the change was? (For future experiments, please describe the change + send me the log + build scan. Thanks!)
to...@gmail.com
I just added a new flag to the existing intent. So I added one more intent.setFlag() to here
public static void callWithShortcutFlow(@NonNull Context context, @ShortcutFlow final String shortcutFlow) {
final Intent intent = new Intent(context, DashboardActivity.class);
intent.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
context.startActivity(intent);
}
public static void callWithShortcutFlow(@NonNull Context context, @ShortcutFlow final String shortcutFlow) {
final Intent intent = new Intent(context, DashboardActivity.class);
intent.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
context.startActivity(intent);
}
hu...@google.com
Can you send me the contents of DashboardActivity (after removing any confidential stuff)?
Can you retry with a change that does not involve a flag or a constant?
Can you retry with a change that does not involve a flag or a constant?
to...@gmail.com
I understand that change the value of constant needs to recompile but just use of constant... Constants are used almost everywhere.
So I tried to change the string value, change the value of a primitive type local variable, add else branch, remove else branch and also add one simple indentation space and it always ends with "Full recompilation" in the log.
Then I created new unused class and there was possible do changes without "Full recompilation" in the log.
But when I started using this class in my project, it stops incremental compilation again.
So it looks that incremental compilation is a very sensitive thing.
So I tried to change the string value, change the value of a primitive type local variable, add else branch, remove else branch and also add one simple indentation space and it always ends with "Full recompilation" in the log.
Then I created new unused class and there was possible do changes without "Full recompilation" in the log.
But when I started using this class in my project, it stops incremental compilation again.
So it looks that incremental compilation is a very sensitive thing.
to...@gmail.com
.
hu...@google.com
There are cases that Gradle has to do full recompilation, but it shouldn't be that common. If adding spaces causes full recompile, then it is probably a Gradle bug. If you could share a project (either real or artificial) that shows these issues, I will try to find out what happens.
to...@gmail.com
It's incremental data binding annotation processor already implemented in the latest 3.4 beta release of build plugin, please?
I'm expecting that in 3.3 not.
Thanks.
I'm expecting that in 3.3 not.
Thanks.
hu...@google.com
It is being scheduled for 3.5. I am expecting to release this feature to 3.5 canaries soon (within a week or two).
to...@gmail.com
Thanks a lot!
hu...@google.com
I am pleased to inform that data binding has become incremental, starting with AGP 3.5.0-alpha05. For safety we've put this feature behind a flag, currently off by default. To enable it, please set
android.databinding.incremental=true
in the Gradle properties file.
Relevant commit:https://android.googlesource.com/platform/tools/base/+/85292f7e7b41e741fe5354d31a30c97ec79d18a6
Please try out the feature and let us know how it goes. If we receive enough good feedback, we will enable it by default. I'm leaving this bug open to keep track of that.
android.databinding.incremental=true
in the Gradle properties file.
Relevant commit:
Please try out the feature and let us know how it goes. If we receive enough good feedback, we will enable it by default. I'm leaving this bug open to keep track of that.
to...@gmail.com
Thanks a lot! Currently, I'm testing 3.4.0 version. I will try 3.5.0 ASAP.
an...@gmail.com
In response to #29, any feedback yet from you or anyone else with this flag? If it works out, this could be a huge productivity gain. Will try for myself ASAP.
to...@gmail.com
I just tested it on a relatively small project and it looks good, here is incremental build, with one line changed
https://scans.gradle.com/s/bt2obrtrrrj2y/timeline?task=arbuq4molzx42
And here a clean compilation
https://scans.gradle.com/s/4talkldkc2qro/timeline?task=arbuq4molzx42
According to logs, it looks that incremental compilation was used. I'm using data binding, Glide, and Butterknife
But I need to test it on a bigger project, where compilation takes 30s
And here a clean compilation
According to logs, it looks that incremental compilation was used. I'm using data binding, Glide, and Butterknife
But I need to test it on a bigger project, where compilation takes 30s
pj...@gmail.com
I did a test on a big project and the incremental compiling didn't work.
https://scans.gradle.com/s/b3qs53n4silqa/timeline?task=cnfo4lpnihue4
I updated all annotation processors to versions which support incremental compiling and used 3.5.0-alpha05
I changed just two lines of code in java
I updated all annotation processors to versions which support incremental compiling and used 3.5.0-alpha05
I changed just two lines of code in java
to...@gmail.com
I also tested it on a large and very complex project already.
Here is build without any changes in the code, it takes just 8s
https://gradle.com/s/2xhpe7aamx7uw
And here I just commented out one line of code in the fragment, no method signature change
https://gradle.com/s/e7iuvbqttdxn2
It takes 40s, just compiling java code is 12shttps://scans.gradle.com/s/e7iuvbqttdxn2/timeline?task=a2moppdi3f2qu
In log is
Compiling with JDK Java compiler API.
Incremental compilation of 688 classes completed in 10.061 secs.
There is no information, that something prevents to incremental compilation
So hard to say if "compilation of 688 classes" means that it really compile all of them, because just one file was changed or it means the total class count.
When I delete build folder and turn off build cache, the build takes 1m 10s, and just the compilation takes 11.2s
https://scans.gradle.com/s/3qas6nl3ze3c6/timeline?task=a2moppdi3f2qu
So from this looks that 11s is time for full compilation, not an incremental one.
Btw. Do the build with deleted build folder and without build cache with the build plugin 3.3.1 takes 1m 31s.
So it looks that 3.5 brings 23% increase of speed build, but I did not enough measures to prove it. It is just from one build.
https://gradle.com/s/tdgnlpokgs5zi
All tests are from the command line, I did not run the build directly from IDE.
Here is build without any changes in the code, it takes just 8s
And here I just commented out one line of code in the fragment, no method signature change
It takes 40s, just compiling java code is 12s
In log is
Compiling with JDK Java compiler API.
Incremental compilation of 688 classes completed in 10.061 secs.
There is no information, that something prevents to incremental compilation
So hard to say if "compilation of 688 classes" means that it really compile all of them, because just one file was changed or it means the total class count.
When I delete build folder and turn off build cache, the build takes 1m 10s, and just the compilation takes 11.2s
So from this looks that 11s is time for full compilation, not an incremental one.
Btw. Do the build with deleted build folder and without build cache with the build plugin 3.3.1 takes 1m 31s.
So it looks that 3.5 brings 23% increase of speed build, but I did not enough measures to prove it. It is just from one build.
All tests are from the command line, I did not run the build directly from IDE.
pj...@gmail.com
I forgot to add that I'm using
apply plugin: "kotlin-android"
as some code is written in kotlin however I'm using java annotation processor - not kapt
apply plugin: "kotlin-android"
as some code is written in kotlin however I'm using java annotation processor - not kapt
to...@gmail.com
I have also Kotlin code in the project, but I'm using just java annotation process also.
hu...@google.com
@32, 34: Can you run with --info to see whether Java compile in your project is incremental and how many classes are recompiled?
@33, 35: "Incremental compilation of 688 classes completed in 10.061 secs." => This means that Java compile is incremental in your project. 688 of all the classes are actually recompiled. The number of recompiled classes depends on the nature of the change. You can try changing a class that is not used by any other class, and observe that the number of recompiled classes will be much lower.
If the number of recompiled classes is always high for you, can you run with --debug and attach the log here? It will show exactly what classes are recompiled, and we can debug from there. Note that it's enough to just run the Java compile task, and make sure you remove any confidential info if any from the log first.
@33, 35: "Incremental compilation of 688 classes completed in 10.061 secs." => This means that Java compile is incremental in your project. 688 of all the classes are actually recompiled. The number of recompiled classes depends on the nature of the change. You can try changing a class that is not used by any other class, and observe that the number of recompiled classes will be much lower.
If the number of recompiled classes is always high for you, can you run with --debug and attach the log here? It will show exactly what classes are recompiled, and we can debug from there. Note that it's enough to just run the Java compile task, and make sure you remove any confidential info if any from the log first.
to...@gmail.com
I changed one line in Activity class it is definitely not used in any other class. I will try it with debug and send log here later today.
pj...@gmail.com
From the huge log I extracted this
" Full recompilation is required because com.google.auto.value.processor.AutoValueProcessor is not incremental. Analysis took 5.306 secs. "
the dex task detected the single file change
"AnalyticsManager.dex:CHANGED"
I'm using AutoValue 1.6.3 and according to release notes it should be incremental
https://github.com/google/auto/releases/tag/auto-value-1.6.3
Gradle doesn't report it as "non-incremental" as it used to be with older version.
" Full recompilation is required because com.google.auto.value.processor.AutoValueProcessor is not incremental. Analysis took 5.306 secs. "
the dex task detected the single file change
"AnalyticsManager.dex:CHANGED"
I'm using AutoValue 1.6.3 and according to release notes it should be incremental
Gradle doesn't report it as "non-incremental" as it used to be with older version.
to...@gmail.com
I found just this
01:38:54.680 [INFO] [org.gradle.api.internal.tasks.compile.incremental.SelectiveCompiler] Full recompilation is required because 'DashboardActivity.java' was changed. Analysis took 0.251 secs.
I just added line
i.putExtra(ACTION, action);
to method creating Intent like this
Intent i = new Intent(activity, DashboardActivity.class);
i.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
activity.startActivity(i);
inside of DashboardActivity.java
01:38:54.680 [INFO] [org.gradle.api.internal.tasks.compile.incremental.SelectiveCompiler] Full recompilation is required because 'DashboardActivity.java' was changed. Analysis took 0.251 secs.
I just added line
i.putExtra(ACTION, action);
to method creating Intent like this
Intent i = new Intent(activity, DashboardActivity.class);
i.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
activity.startActivity(i);
inside of DashboardActivity.java
hu...@google.com
@38: AutoValue will not be incremental if one of its extensions is not incremental. Please follow the progress for AutoValue extensions here: https://github.com/google/auto/issues/673
@39: This appears to be a Gradle bug. Could you prepare a small project and file a bug with Gradle? You can also attach the project here, and I will try to see what's wrong.
@39: This appears to be a Gradle bug. Could you prepare a small project and file a bug with Gradle? You can also attach the project here, and I will try to see what's wrong.
pj...@gmail.com
I found that auto-value-parcel is not incremental. Author still didn't release the new version but with help of jitpack I managed to make all my dependencies support incremental compiling.
However when I change a single file the whole module is being recompiled
Task ':app:compileGrubhubStagingJavaWithJavac' is not up-to-date because:
Input property 'sources' file /Users/rudy/dev/projects/dinerapp-android/app/src/main/java/com/grubhub/dinerapp/android/order/search/searchResults/data/SearchResponseTransformer.java has changed.
Compiling with source level 1.8 and target level 1.8.
file or directory '/Users/rudy/dev/projects/dinerapp-android/app/libs', not found
Created classpath snapshot for incremental compilation in 0.005 secs.
Class dependency analysis for incremental compilation took 0.165 secs.
Compiling with JDK Java compiler API.
Incremental compilation of 2923 classes completed in 28.813 secs.
Packing task ':app:compileGrubhubStagingJavaWithJavac'
Is there something I'm missing ?
However when I change a single file the whole module is being recompiled
Task ':app:compileGrubhubStagingJavaWithJavac' is not up-to-date because:
Input property 'sources' file /Users/rudy/dev/projects/dinerapp-android/app/src/main/java/com/grubhub/dinerapp/android/order/search/searchResults/data/SearchResponseTransformer.java has changed.
Compiling with source level 1.8 and target level 1.8.
file or directory '/Users/rudy/dev/projects/dinerapp-android/app/libs', not found
Created classpath snapshot for incremental compilation in 0.005 secs.
Class dependency analysis for incremental compilation took 0.165 secs.
Compiling with JDK Java compiler API.
Incremental compilation of 2923 classes completed in 28.813 secs.
Packing task ':app:compileGrubhubStagingJavaWithJavac'
Is there something I'm missing ?
hu...@google.com
"Incremental compilation of 2923 classes completed in 28.813 secs." => This indicates that the Java compile task in your project was already incremental; otherwise you would have seen a message like "Full recompilation is required because <something happened>".
When Java compile is incremental and you still see a lot of classes are recompiled, it usually means that the specific change that you make to the source file affects a lot of classes (especially if you make a change relating to constants). Seehttps://docs.gradle.org/current/userguide/java_plugin.html#sec:incremental_compile for more background.
If you change a different source file with a different type of change (e.g., adding a comment or modifying a method's body), you'll probably notice that the set of recompiled classes will be much smaller.
When Java compile is incremental and you still see a lot of classes are recompiled, it usually means that the specific change that you make to the source file affects a lot of classes (especially if you make a change relating to constants). See
If you change a different source file with a different type of change (e.g., adding a comment or modifying a method's body), you'll probably notice that the set of recompiled classes will be much smaller.
hu...@google.com
Starting with AGP 3.6.0-alpha02, we are enabling incremental data binding by default. Please let us know if you see more improvements in your build.
Change:https://android.googlesource.com/platform/tools/base/+/399103996d94d961fe82ca82cd0cffdfe3044f29
Since next week will be our last check-in date for 3.5.0-rc01, I feel that cherry-picking this change back to 3.5 is a bit risky.
@Jerome: Please let me know if you think cherry-picking to 3.5 still makes sense.
Change:
Since next week will be our last check-in date for 3.5.0-rc01, I feel that cherry-picking this change back to 3.5 is a bit risky.
@Jerome: Please let me know if you think cherry-picking to 3.5 still makes sense.
to...@gmail.com
Only blocking thing for me is still Room library, but it also looks that version with incremental support will be available really fast.
I meantime changed also java annotation processor to kapt. So I'm curious if I will still have an issue with it as I have so far like every minimal code change always caused full recompilation.
I meantime changed also java annotation processor to kapt. So I'm curious if I will still have an issue with it as I have so far like every minimal code change always caused full recompilation.
hu...@google.com
Yes, the work to make Room incremental is tracked at
Please open a new bug with us if you think your build is still not as fast as expected.
>> every minimal code change always caused full recompilation
I would be very interested to find out, but as discussed above, would need a demo project to identify the issue.
Please open a new bug with us if you think your build is still not as fast as expected.
>> every minimal code change always caused full recompilation
I would be very interested to find out, but as discussed above, would need a demo project to identify the issue.
to...@gmail.com
>> every minimal code change always caused full recompilation
I would be very interested to find out, but as discussed above, would need a demo project to identify the issue.
I know, but not happen on small demo project, its happen only on the big one. I will investigate it more.
I would be very interested to find out, but as discussed above, would need a demo project to identify the issue.
I know, but not happen on small demo project, its happen only on the big one. I will investigate it more.
pj...@gmail.com
I updated project to use 3.5.0-rc03 and enabled android.databinding.incremental=true
I made change in single file and rerun the compilation. Got such output
"Full recompilation is required because 'AppUtils.java' was changed. Analysis took 0.162 secs."
I added few lines in the file but I don't understand why it needed to do full recompilation.
Is there a flag or other debug method that would tell me more about the case?
I made change in single file and rerun the compilation. Got such output
"Full recompilation is required because 'AppUtils.java' was changed. Analysis took 0.162 secs."
I added few lines in the file but I don't understand why it needed to do full recompilation.
Is there a flag or other debug method that would tell me more about the case?
[Deleted User] <[Deleted User]>
>>> I added few lines in the file but I don't understand why it needed to do full recompilation.
Might be due tohttps://github.com/gradle/gradle/issues/2767#issuecomment-323975456
Might be due to
hu...@google.com
Yes, that seems to explain it. A workaround is also posted on that bug: https://github.com/gradle/gradle/issues/2767#issuecomment-362192761
This situation has actually already been documented in the Gradle docs (https://docs.gradle.org/current/userguide/java_plugin.html#sec:incremental_compile ): "Since constants can be inlined, any change to [*** a class containing ***] a constant will result in Gradle recompiling all source files. For that reason, you should try to minimize the use of constants in your source code and replace them with static methods where possible". Note that the docs should probably say "any change to a class containing a constant" instead of "any change to a constant".
Here is the bug that tracks the work to improve this:https://github.com/gradle/gradle/issues/6482 .
This situation has actually already been documented in the Gradle docs (
Here is the bug that tracks the work to improve this:
[Deleted User] <[Deleted User]>
I commented[1] on the issue about the misleading documentation. Assuming we're right, it will be trivial to update the docs to reflect the full reality.
[1]https://github.com/gradle/gradle/issues/6482#issuecomment-522672671
[1]
ky...@gmail.com
guys anyone had the same issue C:\Users\Edgar\Desktop\GithubTask\app\build\generated\data_binding_base_class_source_out\debug\dataBindingGenBaseClassesDebug\out\android\com\githubtask\databinding\FragmentRepositoriesBinding.java:20: error: cannot find symbol
public final EditTextSearch etMainSearch;
^
symbol: class EditTextSearch
location: class FragmentRepositoriesBinding
public final EditTextSearch etMainSearch;
^
symbol: class EditTextSearch
location: class FragmentRepositoriesBinding
tu...@gmail.com
Comment has been deleted.
Description
I'm using annotation processor that support this feature already.
List of all is here
But in the build log is still this
"Incremental Java compilation disabled in variant ... as you are using an incompatible plugin"
Without any detailed explanation.
I tried to report it here
But according to Gradle team it comes directly from Android Build plugin.
And Xavier Ducrohet confirm it here:
I tried also to use
android.databinding.enableV2=true
And it doesn't help.
I'm creating this issue to track any further progress of this issue.
I think that incremental compilation can help a lot with our big projects, where just compilation on every run takes almost 40s because everything is recompiled every time.
Android Gradle Plugin: 3.2.0-alpha18
Gradle: 4.8