A11y - Need a way to change manually focus order in Jetpack Compose [186443263]

Fixed

Bug

Status Update

No update yet.

Description

fa...@gmail.com

created issue #1

Apr 27, 2021 06:10PM

Hi

It would be really useful to be able to change focus order as we were able to do it before with accessibilityTraversalAfter accessibilityTraversalBefore.
This feature is a must have, specifically when designing a view on the Z axe to actually specify to talkback in which order to read element.
Moreover, it is also necessary when using a FAB button, if the element behind is an infinite list, we should be able to set the focus to the FAB Button first otherwise the user experience for a blind person is really poor.
Thanks for you work on Jetpack Compose, and keep going !

Comments

so...@google.com <so...@google.com> Apr 27, 2021 06:22PM

Assigned to yi...@google.com.

yi...@google.com <yi...@google.com> #2Apr 27, 2021 06:44PM

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?

am...@twitter.com <am...@twitter.com> #3Apr 27, 2021 06:51PM

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

so...@google.com <so...@google.com> #4Apr 27, 2021 06:52PM

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.

Message last modified on Apr 27, 2021 06:53PM

fa...@gmail.com <fa...@gmail.com> #5Apr 27, 2021 07:08PM

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.

yi...@google.com <yi...@google.com> #6Apr 27, 2021 07:17PM

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)

fa...@gmail.com <fa...@gmail.com> #7Apr 27, 2021 07:19PM

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!

fa...@gmail.com <fa...@gmail.com> #8Apr 27, 2021 07:23PM

Thank you, I'll try it and check.

am...@twitter.com <am...@twitter.com> #9Apr 27, 2021 07:28PM

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.

yi...@google.com <yi...@google.com> #10Apr 27, 2021 07:44PM

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

ae...@google.com <ae...@google.com> #11Apr 27, 2021 09:13PM

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

pw...@google.com <pw...@google.com> #12Apr 27, 2021 11:46PM

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!

fa...@gmail.com <fa...@gmail.com> #13Apr 28, 2021 06:58AM

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)

Message last modified on May 4, 2021 09:07AM

yi...@google.com <yi...@google.com> #14Jun 23, 2021 02:40AM

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

yi...@google.com <yi...@google.com> #15Jun 23, 2021 02:42AM

Reassigned to ae...@google.com.

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!

he...@ataulm.com <he...@ataulm.com> #16Jun 23, 2021 04:23AM

Added workarounds in Known issues section in public docs.

cb...@google.com <cb...@google.com> #17Jun 23, 2021 07:03PM

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

pb...@google.com <pb...@google.com> #18Jul 7, 2021 08:50PM

Hey, so we are working on App Widgets, and one of the layout we are working with is this: http://screen/3DhenbTZNKtEqXw (only showing the silhouette, as this is under development).

There are five locations for buttons, and iterating through them should probably be from more important to less important, meaning the center first, and then around in a circle, starting probably from top-left, although this might depend on whether the UI is LTR or RTL and on the exact application.

yi...@google.com <yi...@google.com> Jul 8, 2021 02:34AM

Reassigned to pw...@google.com.

pw...@google.com <pw...@google.com> #19Jul 14, 2021 05:40PM

I think #18 illustrates my concern with exposing a traversal API - different developers will have different ideas for what is correct. I think whether to traverse based on importance or location is a TalkBack design question that should be answered inside TalkBack, not driven by individual apps. If different apps make different decisions, the resulting inconsistency will likely be worse than having a single strategy even if that strategy is sub-optimal in some situations.

fa...@gmail.com <fa...@gmail.com> #20Jul 14, 2021 06:31PM

Please think again of cases like the fab button on Gmail. Having the button inaccessible to blind user is not a "sub-optimal" situation. It's an unfair situation and it's not acceptable. Why not letting the developer do what it's necessary ? A developer that cares about impacting the reading order of TalkBack will definitely know better what's the best user experience in its app for its users.
Being able to influence the reading order by importance is really useful to offer a good user experience to blind user.

ro...@gmail.com <ro...@gmail.com> #21Sep 12, 2021 11:59AM

Comment has been deleted.

Message last modified on Sep 12, 2021 11:40PM

lo...@gmail.com <lo...@gmail.com> #22Nov 23, 2021 08:36AM

Blocked by a private issue 😪

da...@omadahealth.com <da...@omadahealth.com> #23Mar 14, 2022 09:15PM

I think not giving power to developer to define custom traversal order for a particular screen is a missed opportunity and it restricts what devs can do with the app. Depending on how the screen is built, with a lot of custom ui and things, it might not always be possible to make things work without making significant change to the ui components. I think it makes sense that google want to define its rules for accessibility and enforce them a bit. It may provide more consistency across the apps, and this is helpful for the apps that want to do minimal work for accessibility, when the app is constructed purely out of basic components. I think it's really restrictive to not grant finer controls for accessibility things, because it ends up really affecting the design of components/screens for the non-vision impaired users. As it stands now, it wouldn't be about making a small compromise to make things work well for both population, which would be totally fine, but it would basically because we can't technically accomplish something for vision impaired users with certain ui, so then we have to sometimes completely re think of the design for regular population. Again, because of technical limitation, not because the design wasn't thoughtfully done for vision-impaired users.

Building rich experience for vision impaired users aren't easy, but I think we should embrace that fact and give more tools and education for the devs, so when we are building complex things, we have all the tools in our disposal.

Message last modified on Mar 14, 2022 09:23PM

al...@dayforce.com <al...@dayforce.com> #24Mar 15, 2022 03:29PM

Agree with #23. It would be ideal to have the tools and implement them on a case-by-case for some of our more complex components. I don't believe anyone wants to make inconsistent behaviour for end-users but getting to that consistent behaviour should be available to us if the default implementation can't reach it in this case. It's problematic for us when our expected traversal order in design (which may be set by accessibility analysts) doesn't meet our actual implementation and sometimes the design/implementation refactor costs are high.

While not on compose, there's been issues in the past with traversal where even with refactors we couldn't get an expected result leading to difficult decisions, which is not ideal for end-users.

Let us take responsibility for meeting the compliance, consistency, and accessibility of our own implementation.

ae...@google.com <ae...@google.com> #25Mar 26, 2022 12:58AM

Thanks for the feedback. What I would find helpful to make progress here is to hear the concrete cases you're running into where the default order deviates from the one your a11y analysts recommend. Feel free to file those as separate bugs under the following component: https://issuetracker.google.com/issues/new?component=1070466

Then, case by case, we could: 1) suggest a technical workaround to make the order conform without redesigning your app, 2) fix our implementation so that the default order conforms to what you want, or 3) acknowledge that it is technically impossible right now and block those bugs on this feature request. If we wind up accumulating a critical mass of case 3), that would justify putting this on our roadmap, as well as making sure that it supports all the motivating use cases.

al...@gmail.com <al...@gmail.com> #26May 17, 2022 07:06PM

Here is an example:

I have a list item (see screenshot) where there is Text, Detail Text, and Meta text. I want these to be announced in that same order.

However, talkback announces the order by default like "Text, Meta text, Detail text".

I believe this is because my layout is like this:

Column {
    Row { 
        Text()
        MetaText()
    }
    DetailText()
}

So I think the only way I could workaround this is by creating a custom layout that places the composables in the same order that they should be read out loud in talkback. But this isn't very convenient.

Screen Shot 2022-05-17 at 3.00.02 PM.png

79 KB

View

Download

pw...@google.com <pw...@google.com> May 29, 2022 09:45PM

Reassigned to an...@google.com.

va...@google.com <va...@google.com> #27Jul 21, 2022 12:21AM

Another use case: https://github.com/google/accompanist/issues/1254

In short, there is a topBar in a Scaffold that is being placed in the same location as the content slot (and the content is given the space that the top bar occupies as padding values via subcomposition)

Since topBar and content are placed at the same location, the logic in SemanticsSort eventually choose the content first, since it is a taller element: https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/semantics/SemanticsSort.kt;l=130;drc=627183600bfd9920c47bd26bdfe5ec906b54d2a7

That is unexpected, however, since the topBar will visually be the top-most element. There doesn't appear to be any way currently to affect this ordering, other than by changing where the topBar and content are placed.

The same issue is also currently affecting the M3 Scaffold for the same reason.

ae...@google.com <ae...@google.com> #28Jul 21, 2022 12:26AM

Indeed, so far, more than half the focus-traversal problem cases I've heard involve a top bar. We'll see what we can do to improve that particular use case.

ap...@google.com <ap...@google.com> #29Nov 10, 2022 10:28PM

Project: platform/frameworks/support
Branch: androidx-main

commit 58ef0380e0f989b7532babbff23bcef0d3ba64b6
Author: Melba Nuzen <mnuzen@google.com>
Date: Thu Oct 27 16:35:09 2022

Internal change from using SemanticsSort to 'setTraversal'

This change is meant to be pre-work for a larger refactoring of focus order in Compose and shouldn’t introduce any changes in A11y behavior.

Issues seen in

b/227206751

and

https://github.com/maxim-pandra/ComplexAccessibility are part of an problem where parent/child relations in existing Semantics nodes block some ways of ordering—for example, if there were a row containing multiple text elements, then a following button overlaid on the row, TalkBack would read through all text elements before jumping back up the screen to the button. This is because `SemanticsSort` will always read the children of a parent node before moving on. A comparison independent of parent/child hierarchies would read the text children up to where the button element is on the screen, read the button element, and then proceed with the rest of the text children.

This patch is just meant to check that we can use `setTraversalBefore` to determine our own custom order for semantics nodes (overriding the existing hierarchies). `setTraversalValues` in `AndroidComposeViewAccessibilityDelegateCompat` should order semantics nodes in the same way `SemanticsSort` did, except by setting the `traversalBefore` value for each node that will be read by TalkBack.

This ordering is set in a mapping when semantic nodes are first retrieved. Then when a nodeInfo is created, the code now looks up our custom traversal order and uses `setTraversalBefore` on that ANI. That way, when TalkBack goes through the ANI tree, it’ll use the `traversalBefore` parameter and traverse in the way that we want regardless, of parent/child hierarchies.

Bug: 186443263
Test: compose/ui/AndroidAccessibilityTest/testCreateAccessibilityNodeInfo_forTraversalOrder

Change-Id: I339010bea62afb359e63d6e63889acff2c72cf27

M compose/ui/ui/integration-tests/ui-demos/src/main/java/androidx/compose/ui/demos/UiDemos.kt
A compose/ui/ui/integration-tests/ui-demos/src/main/java/androidx/compose/ui/demos/accessibility/ComplexAccessibility.kt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/AndroidAccessibilityTest.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/AndroidComposeViewAccessibilityDelegateCompat.android.kt

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

b....@gmail.com <b....@gmail.com> #30Dec 27, 2022 03:56PM

Here is another example where we think it would be nice to have an API to specify the custom accessibility focus order. Have a look at this repo. We have a LazyRow of tabs and a HorizontalPager. When used with TalkBack, the user has to scroll through all the pages back to the first element of the first page to finally jump out of the Pager and to return to the tabs. The tabs are there to quicken the navigation (the user selects a tab, then the Pager goes straight to its content). So we think it would be nice to allow the user to exit from the current page in the middle of the Pager straight to the active tab - not to the previous page. Maybe, it would also be helpful to automatically focus the page right after the user selects a tab, so it is not required to scroll through all the rest tabs in LazyRow to reach the now-active page.

pager_focus_order.mp4

91 KB

Download

jo...@gmail.com <jo...@gmail.com> #31Apr 20, 2023 08:16AM

Hello, anybody can show a use case of:

modifier = modifier
        .semantics {
            requestFocus(label = "label", action = {
                anyAction()
                true
            } ...

For handle talkback focus

Or:

modifier = modifier
            .semantics {
                focused = false
               ...
to lost a focus and recovery again.

Thanks!

ap...@google.com <ap...@google.com> #32Apr 27, 2023 11:35PM

Project: platform/frameworks/support
Branch: androidx-main

commit c8984d286586fa208df859b6a6f906364db47823
Author: Melba Nuzen <mnuzen@google.com>
Date: Wed Mar 15 11:24:57 2023

Only sort speaking nodes and implement traversal index API

Test: AndroidAccessibilityTest.testSortedAccessibilityNodeInfo_traversalIndex() and others

Bug: 186443263

Relnote: "New semantics property traversalIndex, a float used to reorder nodes in TalkBack traversal (lower values come before)."

The first change in this CL switches the semantics sorting logic so that only `structurallySignificant` or `screenReaderFocusable` nodes are considered in the sorting algorithm. `structurallySignificant` is only true if the node is a container/traversalGroup, or is a scrollable, or has collectionInfo. `screenReaderFocusable` is true when a node will be traversed by TalkBack.

The second change in this CL adds in a `traversalIndex` API that can be used to customize TalkBack traversal order. When the `traversalIndex` semantics property is set on a container/traversalGroup or on a screenreader-focusable node, then the sorting algorithm will prioritize nodes with smaller `traversalIndices` first.

The default traversalIndex value is zero. If a screenreader-focusable node is inside a `traversalGroup`, then it’ll inherit placement of the `traversalGroup`, but inside the `traversalGroup` itself, still have default value of 0. This way, developers can use `traversalIndex` on a group to change the ordering of the group (relative to its peers) as a whole, but still be able to customize the traversal order of the children of that `traversalGroup`.

See go/traversal-index-changes for more details.

Change-Id: I9a81b4acf33c355c1142e28e6fd94788f7937cec

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/integration-tests/ui-demos/src/main/java/androidx/compose/ui/demos/accessibility/ComplexAccessibility.kt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/AndroidAccessibilityTest.kt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/semantics/SemanticsTests.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/AndroidComposeViewAccessibilityDelegateCompat.android.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/semantics/SemanticsProperties.kt

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

lu...@livefront.com <lu...@livefront.com> #33May 19, 2023 09:44PM

Any news on when this fix will actually hit a release? The changes look beautiful!

Message last modified on May 20, 2023 06:38PM

ae...@google.com <ae...@google.com> #34May 19, 2023 10:15PM

The new traversalIndex/traversalGroup SemanticsProperties will first be released in 1.5.0-beta01, scheduled for mid-next-week. We think it should be a flexible tool to improve a11y focus order for many of the known use cases, I hope it solves your problem!

If it doesn't behave as you expect, please post a video along with sample code, and we'll investigate. Also, please note that there are still known issues with TalkBack initial focus after navigation which traversalIndex is not yet able to solve (see b/272065229), so we plan to continue to add more features in this area in Compose 1.6.

Message last modified on May 19, 2023 10:15PM

lu...@livefront.com <lu...@livefront.com> #35May 20, 2023 06:37PM

Greatly appreciated. My use case will definitely put it to the test!

lu...@livefront.com <lu...@livefront.com> #36May 30, 2023 08:44PM

Thank you so much for the travesalIndex/traversalGroup release! It has mostly worked as expected. The one issue I am seeing is when the parent has semantics(mergeDescendants = true) {}. I made an example:

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            TraveralTestTheme {
                TraversalExample(
                    modifier = Modifier
                        .semantics(mergeDescendants = true) {  }
                        .background(color = Color.Gray)
                        .fillMaxSize()
                )
            }
        }
    }
}

@Composable
fun TraversalExample(
    modifier: Modifier = Modifier,
) {
    Row(
        horizontalArrangement = Arrangement.Center,
        verticalAlignment = Alignment.CenterVertically,
        modifier = modifier.semantics { isTraversalGroup = true },
    ){
        Column {
            Text(
                text = "I should be announced first",
                modifier = Modifier
                    .padding(16.dp)
                    .semantics { traversalIndex = 1f },
            )
            Text(
                text = "I should be announced third",
                modifier = Modifier
                    .padding(16.dp)
                    .semantics { traversalIndex = 3f },
            )
        }
        Text(
            text = "I should be announced second",
            modifier = Modifier
                .padding(16.dp)
                .semantics { traversalIndex = 2f },
        )
    }
}

The announcement order is: 1,3,2.

The announced string is: "I should be announced first, I should be announced third, I should be announced second"

ae...@google.com <ae...@google.com> #37May 31, 2023 01:31AM

Got it. traversalIndex's current implementation only control the order that TalkBack moves its focus box around: we hadn't yet considered the use case of controlling the announcement order within a single merged element. Feel free to file a separate bug on that.

For now, clearAndSetSemantics { contentDescription = "I should be announced first, I should be announced second, I should be announced third" } could be an alternate way of solving this, although I recognize clearAndSetSemantics has downsides and it's usually better to avoid it.

lu...@livefront.com <lu...@livefront.com> #38May 31, 2023 02:12PM

OK. I will do that! Thank you very much. I have noticed other interesting behavior but haven't been as successful in reproducing it. We think some of the behavior is related to this:

Also remove the idea of 'structurally significant' to only talk about traversalGroups by adding isTraversalGroup = true to Foundation classes (Modifier.scroll semantics and LazyLayoutSemantics). This way, all scrollables are considered traversalGroups in preparation of aosp/2491418 and go/traversal-index-changes.

as we have solved some of our issues by using Modifier.semantics { isTraversalGroup = false } with scrollable components. The basic description of the issue "the scrollable item seems to be moved deeper into the traversal tree than its peers as it is skipped until the next layer is announced. However, it is properly announced if isTraversalGroup is set to false".

Message last modified on May 31, 2023 02:15PM

ae...@google.com <ae...@google.com> #39May 31, 2023 04:41PM

OK, that sounds like another thing worth filing a separate bug for. We can use your example either to improve our default behavior, or to provide guidance on when to specify isTraversalGroup = false. Please include two videos of what you are seeing (with isTraversalGroup = false on the scrollable, and without).

lu...@livefront.com <lu...@livefront.com> #40May 31, 2023 07:34PM

Of course. Thank you!

lu...@livefront.com <lu...@livefront.com> #41May 31, 2023 07:44PM

I made the issue for that first bug! https://issuetracker.google.com/issues/285043826

eg...@gmail.com <eg...@gmail.com> #42Jun 1, 2023 07:59AM

Thanks for this long waiting feature. During integration we faced runtime crash when we switch compose screens: java.lang.IllegalStateException: LayoutNode should be attached to an owner

ae...@google.com <ae...@google.com> #43Jun 23, 2023 11:11PM

Marked as fixed.

Marking this bug fixed because the new traversalIndex & traversalGroup SemanticsProperties provide the desired manual control of focus order and they are scheduled for release soon in Compose 1.5.

If anyone still can't find a way to solve their use case after experimenting with them, please file a new bug and post a video along with sample code.