Navigation: startActivityForResult analog [79672220]

Fixed

Feature Request

Status Update

No update yet.

Description

ma...@gmail.com

created issue #1

May 14, 2018 04:40PM

From what I see, architecture components does not contain any analog to the startActivityForResult (e.g. displaying a modal
screen that then returns the result to its previous screen).

Is that something planned? How is it expected to create flows like this with current version?

Comments

il...@google.com <il...@google.com> #2May 14, 2018 08:27PM

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?

ne...@gmail.com <ne...@gmail.com> #3May 14, 2018 09:39PM

Tested on Android 12 Emulator with custom executor, but cannot repro this issue.

ma...@gmail.com <ma...@gmail.com> #4May 15, 2018 05:25PM

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.

il...@google.com <il...@google.com> May 25, 2018 08:26PM

Assigned to il...@google.com.

mi...@gmail.com <mi...@gmail.com> #5May 31, 2018 03:30PM

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.

jo...@gmail.com <jo...@gmail.com> #6Jun 15, 2018 09:43AM

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)

il...@google.com <il...@google.com> #7Jun 18, 2018 08:31PM

FYI, ML Kit launched a new language ID SDK in the latest release, which uses a new language ID model. https://developers.google.com/ml-kit/release-notes#august_11_2021

Could you try the new SDK version(17.0.0) to check if you can still repro this native crash? Thanks!

da...@gmail.com <da...@gmail.com> #8Sep 4, 2018 10:15PM

Thank you, I'll try it and check.

il...@google.com <il...@google.com> #9Sep 4, 2018 10:37PM

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.

da...@gmail.com <da...@gmail.com> #10Sep 5, 2018 04:48PM

Also I found there is a post which presents same issue on stackoverflow.

https://stackoverflow.com/questions/68832304/mlkit-translate-sdk-crashes-in-release-build

il...@google.com <il...@google.com> #11Sep 6, 2018 08:03PM

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 inline optimizers on R8 with AGP 7.0, and crash is not reproducible.

$ 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

da...@gmail.com <da...@gmail.com> #12Sep 9, 2018 01:11PM

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!

ar...@gmail.com <ar...@gmail.com> #13Jan 23, 2019 04:38PM

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
- You can see R8 debug mode on build log : https://scans.gradle.com/s/c6h5hy2nxod4u/console-log#L95

Also, I pushed to update MLKit Language Id version 17.0.1 on mlkit17_agp7 branch And here is gradle build scan

https://scans.gradle.com/s/ytaa2kkbp5vc4
- Here is version of com.google.mlkit:language-id

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)

ko...@gmail.com <ko...@gmail.com> #14Feb 22, 2019 09:13AM

Cross-posted on R8 issue tracker. https://issuetracker.google.com/issues/203573699

me...@destil.cz <me...@destil.cz> #15Feb 24, 2019 01:15PM

Hi,

Looks like we figured out the root cause in b/203573699

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!

re...@infinum.com <re...@infinum.com> #16Apr 7, 2019 01:30PM

Added workarounds in Known issues section in public docs.

ko...@gmail.com <ko...@gmail.com> #17Apr 25, 2019 05:15AM

https://issuetracker.google.com/issues/250610583

https://issuetracker.google.com/issues/250609756

https://issuetracker.google.com/issues/250609759

https://issuetracker.google.com/issues/250610272

https://issuetracker.google.com/issues/250610273

https://issuetracker.google.com/issues/250610276

https://issuetracker.google.com/issues/250610278

https://issuetracker.google.com/issues/250610593

https://issuetracker.google.com/issues/250610280

https://issuetracker.google.com/issues/250610923

https://issuetracker.google.com/issues/250610282

https://issuetracker.google.com/issues/250611106

https://issuetracker.google.com/issues/250610598

https://issuetracker.google.com/issues/250611463

https://issuetracker.google.com/issues/250611111

https://issuetracker.google.com/issues/250610933

https://issuetracker.google.com/issues/250610935

https://issuetracker.google.com/issues/250611113

https://issuetracker.google.com/issues/250610937

https://issuetracker.google.com/issues/250611116

https://issuetracker.google.com/issues/250611466

https://issuetracker.google.com/issues/250612724

https://issuetracker.google.com/issues/250612604

https://issuetracker.google.com/issues/250612726

https://issuetracker.google.com/issues/250611471

https://issuetracker.google.com/issues/250177858

https://issuetracker.google.com/issues/250172577

https://www.endezo-it.com/2022/10/the-dark-event-of-indonesian-football.html

https://www.49erssports.com/2022/10/kanjuruhan-tragedy-arema-fc-management.html

https://one-piece-red-full-movie-english.webflow.io/

https://documenter.getpostman.com/view/21828632/2s83tJGAat

am...@gmail.com <am...@gmail.com> #18May 14, 2019 12:57PM

Hi, Its been already a year, is it even planned?

[Deleted User] <[Deleted User]> #19Jul 4, 2019 01:53AM

I will also love to hear nice call back to fragments.

ar...@gmail.com <ar...@gmail.com> #20Jul 12, 2019 11:53AM

Still waiting for this feature implementation.

si...@gmail.com <si...@gmail.com> #21Jul 24, 2019 03:53PM

Would highly appreciate this feature. Having a shared view model sounds like a workaround for me.

il...@google.com <il...@google.com> Jul 29, 2019 07:22PM

Reassigned to jb...@google.com.

ke...@map72.com <ke...@map72.com> #22Aug 7, 2019 07:57PM

Hi. Hope this feature will be implemented soon. Currently, if we search around the web, everyone seems to be using some sorts of workaround for now.

ca...@gmail.com <ca...@gmail.com> #23Aug 29, 2019 01:09AM

Can we get an estimate for when this will be released? This year? Using global shared viewmodels is the one thing that is making navigation code a mess for our app

ke...@gmail.com <ke...@gmail.com> #24Sep 14, 2019 07:34AM

plan to have a second anniversary?

[Deleted User] <[Deleted User]> #25Sep 18, 2019 06:10PM

I would love to have this feature too!

ng...@gmail.com <ng...@gmail.com> #26Sep 28, 2019 03:34AM

I am waiting for the implementation.

ta...@gmail.com <ta...@gmail.com> #27Oct 5, 2019 02:55PM

Is there an ETA for this fix ?

mo...@gmail.com <mo...@gmail.com> #28Oct 6, 2019 06:09AM

Is there a reason why this is prioritized lower? Why isn't it higher? Navigation Component is not feature complete without this...

ca...@gmail.com <ca...@gmail.com> #29Oct 7, 2019 07:25AM

Absolutely agree this should be prioritized higher. Shared viewmodels are not a good substitute for this as they lead to hard to maintain code since fragments start to not be self contained components

ke...@map72.com <ke...@map72.com> #30Oct 7, 2019 10:29AM

Is there anyone in Google we can contact to highlight this issue?

il...@google.com <il...@google.com> #31Oct 7, 2019 10:44PM

This is still on our radar. Staring the issue is enough, commenting and sending a notification to everyone is not necessary.

is...@gmail.com <is...@gmail.com> #32Oct 10, 2019 12:46PM

#MeToo

am...@gmail.com <am...@gmail.com> #33Oct 24, 2019 02:55PM

Please do it!
SharedViewModel fits well in cases where you have a known Subflow where each internal Fragment of this Subflow share/know about the same Subflow Logic and they know about each other.
However, when you want to trespass Subflow boundaries, lets say Subflow_1 launches Subflow_2 and expect a result back. Creating a SharedViewModel for this will pollute the code with a SharedViewModel per Subflow pair. Understand a Subflow could be a single Fragment, for instance a dialog that collects some User data and returns a result to whomever launched it.
Having a feature like this would be great. People including me will clean our code full of workarounds to achieve this.
What I currently do, I have an Activity scoped ViewModel shared by all the Fragments. This ViewModel I named MailBoxStore, that has internally MailBoxes. Each MailBox has the FragmentID it corresponds to. Actually each Fragment has 2 MailBoxes, one for Results and one for Inputs.
Every time a fragment is started after a navigation move, it ask the MailBoxStore if someone sent him either an Input or a Result. Depending on the type of message sent it will call then two methods like onStartWithInput or onFragmentResult.
I really would love a feature like this built in.
Also if the result could be an instance reference and not a Serializable Bundle, it would be much better!

Thanks

li...@booking.com <li...@booking.com> #34Nov 3, 2019 12:23PM

vi...@gmail.com <vi...@gmail.com> #35Nov 5, 2019 11:47PM

+1 also would love to see this

b9...@gmail.com <b9...@gmail.com> #36Nov 6, 2019 04:38AM

Is it possible stopping posting +1? I only want to receive notification about the REAL change about this issue. Thanks.

[Deleted User] <[Deleted User]> #37Nov 6, 2019 09:00AM

Everybody please just STAR the issue, it raises its priority in the issue tracker and subscribes you to email updates, so please stop with +1. Just STAR. Besides, they already confirmed to be working on this at the Android Dev Summit, checkout

https://www.youtube.com/watch?v=RS1IACnZLy4

ra...@gmail.com <ra...@gmail.com> #38Nov 20, 2019 11:26AM

+1 targetFragment/setTargetFragment

mo...@tikalk.com <mo...@tikalk.com> #39Nov 24, 2019 08:03AM

ka...@gmail.com <ka...@gmail.com> #40Nov 27, 2019 10:57AM

al...@gmail.com <al...@gmail.com> #41Nov 27, 2019 12:12PM

te...@gmail.com <te...@gmail.com> #42Nov 28, 2019 08:08AM

mo...@gmail.com <mo...@gmail.com> #43Dec 16, 2019 07:08AM

he...@gmail.com <he...@gmail.com> #44Jan 3, 2020 08:37AM

as...@gmail.com <as...@gmail.com> #45Jan 3, 2020 09:51AM

It's been said before, but please, please people, just star the issue to inform the team that this affecting the issue and to receive notification updates, the team is already working on this as mentioned at the Android Summit. Please do not add "+1" as this emails everybody in the thread.

ca...@gmail.com <ca...@gmail.com> #46Jan 12, 2020 10:01PM

Soon there will be 2 years on this!!! Any news?? I mean, i had seen a turtle moving faster than this, making thinks working proper like navigation bottom (graph per button with proper back navigation as youtube, i mean you are using it, that means is the right way), modals with result back, fragment with result back to previous fragment,etc. Sorry, for the comment but is frustrating for developers to use so many works around on a library that is supposed to improve our lifes!!!

ka...@gmail.com <ka...@gmail.com> #47Jan 13, 2020 04:20AM

You can pass result from a DialogFragment back to a hosting fragment by calling primaryNavigationFragment?.onActivityResult(...) from your DialogFragment.

As for BottomNavigationView - you can make it work by using code from the sample project provided by the team.

Also there's no need to be rude to the team or express your frustration to everyone who starred the issue.

ca...@gmail.com <ca...@gmail.com> #48Jan 13, 2020 05:21AM

Ok, so first i wasnt rude just as i said in the end: only frustrated like almost any android developer using navigation component, it has been and still be a very long long waiting, for official stuff to appear to fix the issues.

So lets start again, the "work around" u mention about DialogFragment does not appear on any docs only the sharedViewModel "work around" if u can call it as that, second the "work arround" for bottomNavigationView has a lots of problems, the back navigation is not working as expected and also has a lots of open issues and nobody from google is answering to those..

ca...@gmail.com <ca...@gmail.com> #49Feb 1, 2020 11:06AM

I want this too.

vi...@gmail.com <vi...@gmail.com> #50Feb 1, 2020 04:42PM

Just add a +1 next time

ri...@gmail.com <ri...@gmail.com> #51Feb 7, 2020 05:01PM

ap...@google.com <ap...@google.com> #52Feb 11, 2020 12:31AM

Project: platform/frameworks/support
Branch: androidx-master-dev

commit e493164e9a9ca69485b2642580134417b7d20aab
Author: Jeremy Woods <jbwoods@google.com>
Date: Mon Feb 10 01:44:58 2020

Provide getSavedStateHandle() on NavBackStackEntry

Added an API to allow users to retrieve a SavedStateHandle from a
NavBackStackEntry. Using the SavedStateHandle, users can store
Parcelable and Serializable objects on the NavBackStackEntry that will
persist over process death.

Test: Added NavBackStackEntryTest tests
Bug: 79672220
Change-Id: I81bb4b11581d2f6ac43afab5aa29a888f38286c0

M navigation/navigation-runtime/api/2.3.0-alpha02.txt
M navigation/navigation-runtime/api/current.txt
M navigation/navigation-runtime/api/public_plus_experimental_2.3.0-alpha02.txt
M navigation/navigation-runtime/api/public_plus_experimental_current.txt
M navigation/navigation-runtime/api/restricted_2.3.0-alpha02.txt
M navigation/navigation-runtime/api/restricted_current.txt
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavBackStackEntryTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavBackStackEntry.java

https://android-review.googlesource.com/1230055

ap...@google.com <ap...@google.com> #53Feb 11, 2020 12:31AM

Project: platform/frameworks/support
Branch: androidx-master-dev

commit 9e9ad24016a882826334b9793af9006d06fb8a30
Author: Jeremy Woods <jbwoods@google.com>
Date: Fri Feb 07 14:40:33 2020

Add getPreviousBackStackEntry() to NavController

Added a method that allows users to get the previous visible
NavBackStackEntry. (This means that it will not return NavGraphs)

Test: Added NavControllerTest
Bug: 79672220
Change-Id: I9486f8e3344bbce477a64b42adc933552c7f2c79

M navigation/navigation-runtime/api/2.3.0-alpha02.txt
M navigation/navigation-runtime/api/current.txt
M navigation/navigation-runtime/api/public_plus_experimental_2.3.0-alpha02.txt
M navigation/navigation-runtime/api/public_plus_experimental_current.txt
M navigation/navigation-runtime/api/restricted_2.3.0-alpha02.txt
M navigation/navigation-runtime/api/restricted_current.txt
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.java

https://android-review.googlesource.com/1230052

ap...@google.com <ap...@google.com> #54Feb 11, 2020 12:31AM

Project: platform/frameworks/support
Branch: androidx-master-dev

commit 316d65d9645ba5eff8146e23616c09288a603419
Author: Jeremy Woods <jbwoods@google.com>
Date: Fri Feb 07 14:39:01 2020

Add getCurrentBackStackEntry to NavController

Adding a convenience method to allow users to get the topmost
NavBackStackEntry instead of using getBackStackEntry() and
getCurrentDestination().

Also rewrote getCurrentDestination to use the new
getCurrentBackStackEntry.

Test: Added NavControllerTest
Bug: 79672220
Change-Id: I1477150b586fd8d26a63b99dc03cd839442e775c

M navigation/navigation-runtime/api/2.3.0-alpha02.txt
M navigation/navigation-runtime/api/current.txt
M navigation/navigation-runtime/api/public_plus_experimental_2.3.0-alpha02.txt
M navigation/navigation-runtime/api/public_plus_experimental_current.txt
M navigation/navigation-runtime/api/restricted_2.3.0-alpha02.txt
M navigation/navigation-runtime/api/restricted_current.txt
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.java

https://android-review.googlesource.com/1229722

jb...@google.com <jb...@google.com> #55Feb 11, 2020 01:05AM

Marked as fixed.

This has been fixed internally and will be available in the Navigation 2.3.0-alpha02 release.

With this change, you can now get a SavedStateHandle from a NavBackStackEntry and use the given SavedStateHandle to pass a result between two entries.

If Fragment A needs a result from Fragment B..

A should get the savedStateHandle from the currentBackStackEntry, call getLiveData providing a key and observe the result.

findNavController().currentBackStackEntry?.savedStateHandle?.getLiveData<Type>("key")?.observe(
    viewLifecycleOwner) {result ->
    // Do something with the result.
}

B should get the savedStateHandle from the previousBackStackEntry, and set the result with the same key as the LiveData in A

findNavController().previousBackStackEntry?.savedStateHandle?.set("key", result)

Because this uses SavedStateHandle, all results need to be types that can be added to a Bundle (i.e Parcelable, Serializable, etc.).

ia...@gmail.com <ia...@gmail.com> #56Apr 2, 2020 10:53AM

if i FragmentA --> FragmentB --> FragmentC then send some params to FragmentA
How do I

[Deleted User] <[Deleted User]> #57Apr 2, 2020 11:03AM

You could theoretically instead "previousBackStackEntry" use "getBackStackEntry(int destinationId)" and get its' savedStateHandle.. But it would be a very bad practice to hardcode a fragment to return it's result 2 steps back..

For your use case it's much more appropriate to use navGraphScoped ViewModel which would be common and shared among all A, B, C:

https://developer.android.com/reference/kotlin/androidx/navigation/package-summary#navgraphviewmodels

Or just pass it back through B...

mo...@gmail.com <mo...@gmail.com> #58Apr 3, 2020 01:08PM

The result value is still set even when I leave Fragment A and open it again, it's like the result is scoped to the container activity.

il...@google.com <il...@google.com> #59Apr 3, 2020 04:28PM

Re #58 - the documentation specifically calls out:

If you’d only like to handle a result only once, you must call remove() on the SavedStateHandle to clear the result. If you do not remove the result, the LiveData will continue to return the last result to any new Observer instances.

The result is scoped to the NavBackStackEntry you access and will otherwise live as long as that destination is on the back stack.

[Deleted User] <[Deleted User]> #60Apr 12, 2020 05:02PM

@Google: I'd like "previousBackStackEntry?.savedStateHandle" to be able to reference previous-Fragment-ViewModels' SavedStateHandle, not just from the Fragment itself.

My "previous" Fragment has a ViewModel with SavedState handle, and right now I have to forward Fragments' SavedState handle into the ViewModel even though the ViewModel has it's own SavedState handle...

Or am I missing something? How can I reference ViewModel of the previousBackStackEntry and its' SavedStateHandle?

il...@google.com <il...@google.com> #61Apr 13, 2020 08:32PM

Re #60 - there's two separate things to keep in mind:

previousBackStackEntry is not tied to your Fragment at all, it is agnostic to what type of destination you are using (it would equally well if you were using Views or Composables for your destinations). It therefore provides no way to access anything related to your Fragment. This is intentional.
A NavBackStackEntry (such as the one returned by previousBackSTackEntry) is a ViewModelStoreOwner and therefore can be used to store any ViewModels you want via by navGraphViewModels(R.id.your_previous_id) or by viewModels({ findNavController().previousBackStackEntry!!}). The SavedStateHandle we provide is just a shorthand for creating a ViewModel in the NavBackStackEntry and getting its SavedStateHandle.

re...@lunabee.com <re...@lunabee.com> #62Apr 13, 2020 11:30PM

Re #57

You could theoretically instead "previousBackStackEntry" use "getBackStackEntry(int destinationId)" and get its' savedStateHandle.. But it would be a very bad practice to hardcode a fragment to return it's result 2 steps back..
For your use case it's much more appropriate to use navGraphScoped ViewModel which would be common and shared among all A, B, C: https://developer.android.com/reference/kotlin/androidx/navigation/package-summary#navgraphviewmodels.
Or just pass it back through B...

What if I want to reuse fragments B&C in another nested graph so I don't want to hardcode the nav graph id in navGraphScoped? The only solution I found is to pass the graph id trough fragment args.

il...@google.com <il...@google.com> #63Apr 13, 2020 11:33PM

Re #62 - that's certainly a valid option if you want to deliver results to a specific destination on your back stack. previousBackStackEntry is just a helper for the most common case, nothing more.

[Deleted User] <[Deleted User]> #64Apr 14, 2020 07:12PM

Re #61 - Thank you! I made it work by using "current" and "previous" back stack entry as the ViewModelStoreOwner for the specific ViewModel I was fetching... instead of calling "getSavedStateHandle()" on the back stack entry itself.

lc...@gmail.com <lc...@gmail.com> #65May 7, 2020 05:38AM

does

https://developer.android.com/reference/androidx/fragment/app/FragmentManager#setfragmentresultlistener apply for fragment destination of a navigation component?

il...@google.com <il...@google.com> #66May 7, 2020 09:48PM

Re #65 - yes, you can use the new Fragment Result APIs between Fragments when using the Navigation Component. Note that much of the Additional Considerations for Dialog destinations have no direct equivalent in the Fragment Result API.

ja...@gmail.com <ja...@gmail.com> #67May 8, 2020 08:19PM

Re #66
hi. i found some issues with this

https://developer.android.com/guide/navigation/navigation-programmatic#additional_considerations

1) in code example..you have 'findNavController()' inside fragment 'onCreate'. When you rotate device app crash due to 'findNavController()' call. I found that when i rotate device then fragment (onCreate) is 'called' first and after that is called 'activity' (onCreate). I think that this is reason why navController is not available and throws this exception: 'Caused by: java.lang.IllegalStateException: NavController is not available before onCreate()'.
2) when i put code inside 'onViewCreated' then 'result' from dialog fragment is correctly propagated into 'previous fragment' but when i rotate device when dialog is shown and then i set 'result' and dialog is closed, no 'result' is received on 'previous fragment'. I guess its because

navBackStackEntry.lifecycle.addObserver(LifecycleEventObserver { _, event ->
if (event == Lifecycle.Event.ON_RESUME) // This event is never 'ON_RESUME' when fragment was recreated in time when dialog was shown

I also tried 'findNavController().currentBackStackEntry?.savedStateHandle?.getLiveData<String>("key")?.observe(viewLifecycleOwner) { //action }' but when device is rotated when 'dialog fragment' is shown, then this live data is not called (otherwise its called fine)

Please can you check this and show us some example how to handle 'dialog fragment' results in previous fragment even when you rotate device when dialog is shown? You can reproduce this issues very easily.

Just small suggested improvement 'navController.currentBackStackEntry!!' -> navController.requireCurrentBackStackEntry()

il...@google.com <il...@google.com> #68May 8, 2020 08:21PM

Re #67 - please see b/154405007 which covers that problem in detail.

b9...@gmail.com <b9...@gmail.com> #69May 9, 2020 02:10AM

#68 Is that link require googler account?

il...@google.com <il...@google.com> #70May 12, 2020 08:49PM

Re #69 - sorry, you'll want to follow the issuetracker.google.com version of that link.

il...@google.com <il...@google.com> #71May 12, 2020 08:50PM

Well, apparently I can't paste links correctly today. It's https://issuetracker.google.com/issues/154405007

br...@gmail.com <br...@gmail.com> #72Jul 22, 2020 04:20PM

I presume that the solution implemented (using backstack entries) won't work when the destination is a new activity, correct? I guess I need use the new registerForActivityResult() system in that case? It would be nice to have a single way of setting up result listeners regardless of whether the destination is an activity or a fragment, but I get why that may be impossible to accomplish, since the new activity doesn't really have a way to access the navcontroller of the previous activity.

lb...@gmail.com <lb...@gmail.com> #73Mar 13, 2023 10:35PM

Isn't there a more elegant, shorter way to do it, other than what's on

comment #55

?
We have registerForActivityResult for Activity which is much nicer.
Why can't we have something like that?
Even the startActivityForResult is easier and shorter to remember than this...

And it's not even clear on