Turns out, telling Android which nodes should be focusable (as we do in flutter/engine#4067) is not enough to convince Android that a node should be focusable.

Example of broken focusability:

              new ListTile(
                onTap: () {
                  print('The ListTile was tapped!');
                },
                trailing: new IconButton(
                  icon: new Icon(Icons.volume_up),
                  onPressed: () {
                    print('The icon was pressed!');
                  },
                ),
              ),

Expectation here is that you can focus the ListTile itself (to trigger the first print) and the encapsulated IconButton (to trigger the second print). However, Android thinks that only the IconButton is focus-worthy even though both nodes are marked as focusable in Android's accessibility tree :

09-13 14:45:43.796 15099 15099 V TreeDebug:               (31061)185Flutter:(0, 280 - 1440, 476):AC:focusable:clickable
09-13 14:45:43.796 15099 15099 V TreeDebug:                 (31092)185Flutter:(1216, 294 - 1384, 462):aC:focusable:clickable

Why's that? Well, Android uses a complicated algorithm to determine if a node should actually be focusable or not (see flow chart on https://code.facebook.com/posts/391276077927020/android-accessibility-debugging-with-stetho/).

Not sure how much of an issue this is. In this particular example its unlikely that in the real world ListTile would not provide a semantics label (which according to the flow chart) would make it focusable. Maybe there are other edge cases that will not resolve that easily?