This function is called too many times. Sometimes this function can take multiple seconds to return. I can't tell why this takes this long.
But, maybe we can cache the result and not calculate this at each call?

+twellington who knows most about Accessibility these days

It seems most likely that this is related to changes I made a couple of milestones ago to enable the accessibility tab switcher when accessibility services that can perform gestures. While I wouldn't have expected the updated logic to be computationally expensive, we do loop over all enabled services in order to do this check

We might be able to cache the value and then listen for accessibility state changes, but we will need to investigate. I'm not sure if the accessibility state change listener is called when the set of enabled accessibility services changes vs only called when the global accessibility state (enabled or disabled) changes.

For future readers, the slow part is isAccessibilityEnabled() here:
https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/util/AccessibilityUtil.java?l=48&rcl=85cd2a967787690bf93c9159734b9e94ad25e852

I believe that one slow part could be the invocation of the AccessibilityManager#getEnabledAccessibilityServiceList() like you said, because it ends up doing a remote invocation, which can sometimes be slow.

I did some log based testing and it seems that AccessibilityStateChangeListener#onAccessibilityStateChange() only gets called when switching from no accessibility services enabled to accessibility services enabled and vice-versa.

Since our heuristic relies on the actual set of services enabled, we can't rely solely on this listener... which actually may be problem with today's implementation since the user could have something like LastPass enabled, where we don't enable the accessibility tab switcher, then turn on TalkBack and we won't execute anything called by ChromeActivity#onAccessibilityStateChange(). But I believe we'll eventually get the UI into the right state, e.g. user can exit and reenter the tab switcher.

The underlying issue is that there are numerous popular apps that use accessibility services for non-accessibility purposes. The biggest difference in UI is the tab switcher, which we received user bug reports about after enabling the accessibility tab switcher for users with accessibility services enabled that state they can perform gestures (issue 839598 and  issue 859401  and b/36513031).

We could enable accessibility mode for all users with any accessibility service enabled and do a better job at promoting the setting that allows them to disable "simplified view for open tabs" (accessibility tab switcher).


I added a new metric tracking users who currently opt-out in 70.0.3511.0: Accessibility.Android.TabSwitcherPreferenceEnabled

It looks like only 4,398/771,632 or 0.5% of users who would normally have the accessibility tab switcher using our current heuristics have opted out.

I plan to add some histograms recording how many users have accessibility services enabled so that we can start to quantify the number of users who would be impacted by our product decisions.

Looks like we already have Accessibility.AndroidServiceInfo that tracks the flags of enabled accessibility services.

For the purposes of this bug I was picturing something like a histogram recorded on deferred startup that tracks the accessibility service type that causes accessibility to be considered enabled (or disabled) (as determined by the first call to AccesibilityUtil#isAccessibilityEnabled). This would miss a lot of cases (e.g. accessibility services enabled/disabled while any Chrome activity is running), but it'd help paint a picture of how many users are affected by the slow performance of the current #isAccessibilityEnabled method and how many additional users would end up with the accessibility tab switcher if we turned it on for all users with any accessibility service enabled.

We'd have something like:
 1) None = no services enabled
 2) Touch exploration = touch exploration is enabled
 3) Switch access
 4) Other service that can perform gestures
 5) Any other accessibility service

Currently 2, 3 & 4 result in #isAccessibilityEnabled returning true. One interesting thing I discovered in testing locally is that when TalkBack is first enabled there are several calls to #isAccessibilityEnabled. The first couple report state #5 before state #2 is entered so it seems that touch exploration being detected labs behind a bit.

We could also do less fine-grained logging and just record 2 boolean histograms reporting whether accessibility is enabled as reported by the accessibility manager and whether AccessibilityUtil#isAccessibilityEnabled returns true on startup or when #onAccessibilityModeChanged is called.

Finally, we could also do logging in AccessibilityUtil#isAccessibilityEnabled, but as ssid@ pointed out this method gets called a lot so we'd generate a lot more data.


+dmazzoni@ - what do you think? Are there any current metrics that might help us answer some of the questions laid out above?

Post holiday ping -- dmazzoni@, please see the questions at the end of comment #7.