Status Update
No update yet.
Comments
ca...@gmail.com
Tested on Android 12 Emulator with custom executor, but cannot repro this issue.
ca...@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.
il...@google.com
ap...@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.
il...@google.com
On the contrary, there was no separate process before, when crashes started.
In the new build (with the aforementioned changes) I can see SIGSEGV crash, but only one instead of dozens and it has a bit different backtrace:
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)
liblanguage_id_jni.so (offset 0x11e000)
backtrace:
#00 pc 000000000003c7c0 /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
#00 pc 000000000003b960 /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
#00 pc 000000000003bb48 /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
#00 pc 000000000003bafc /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
#00 pc 0000000000036c98 /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
#00 pc 0000000000032714 /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
#00 pc 0000000000031cac /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
#00 pc 0000000000057438 /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/oat/arm64/base.odex (offset 0x57000)
Description
Version used: 1.0.0-alpha09
Devices/Android versions reproduced on: N/A
I have started to make use of the Navigation Component and am very please with it. Well done!
Once recommendation I would like to make, however, is to add some better support for configuring custom Destinations when used with the NavHostFragment. The problem that I am having is that in order to configure a custom Destination Navigator, I need to get reference to the NavigatorProvider from the NavController. If I am using a NavHostFragment, then I must first load the Fragment to have its onCreate method called. I then must call navController.navigatorProvider.addNavigator(...) BEFORE I subsequently call navController.setGraph(...). This means that I cannot specify the graph directly in my XML. In fact, if I make use of the app:navGraph attribute I get a crash because my custom Destination nodes have no configured Navigators.
I've looked into extending NavHostFragment with an implementation that automatically calls navigatorProvider.addNavigator(...). But since the NavController is instantiated in NavHostFragment.onCreate() and the XML-configured graph resource ID is handled in the same method, there is no integration point between these 2 operations that allows for additional Navigators to be configured before the graph xml is inflated. As a result the only way that I've found to do the configuration is do the following:
1. Do NOT specify the NavHostFragment via a fragment tag in the XML. Instead add a FrameLayout container.
2. Manually instantiate an instance of NavHostFragment, and load it via a FragmentTransaction.
3. Manually configure the custom Destination Navigator via navHostFragment.navController.navigatorProvider.addNavigator(...)
4. Manually call navHostFragment.navController.setGraph(...)
It's not a huge problem, but it did take a good bit of experimenting before I figured this out. (I.e. the docs for custom destinations could be better.)
Perhaps a later version of NavHostFragment could have an additional overridable method that could be overridden to specify a list of additional Navigators. ?