Calling requestLayout() during a layout pass is inadvisable, but happens often enough in applications (especially when it occurs in very indirect means that the application may not easily be able to control) that we need to handle the situation without breaking. In particular, applications that have run across this problem have had artifacts which are difficult to debug (like things just not showing up on the screen) and also difficult to fix. One of the side-effects of the problem is that it leaves the view hiearchy in an unpredictable state where some views have requested layout and are waiting to be layed out while the root view has not received those requests, so it is never calling layout on those views. The fix is to try to do the 'right' thing, while avoiding getting into an inifinite loop (which could result from calling layout, which calls requestLayout(), which causes another layout, which ...). The solution is two-tier: we handle all requests that happen during layout by delaying them until after the current layout is done. We then process those requests and call layout again. If we receive more requests during that second layout, we post them to the next frame, to allow us to finish the current one. Issue #7155974 handle requestLayout() during layout more robustly Change-Id: I9d13c405be28a19c86add22210e69817ddddaf8b
…
…
…
…
Description
No description provided
Languages
Java
77.3%
Kotlin
9.2%
PowerBuilder
6.6%
C++
5.5%
AIDL
1%