Complete Guide to Updating UI from Background Threads in Android

Android enforces a strict rule that UI components must only be modified on the main (UI) thread. The article begins by showing a common mistake where a background thread directly calls imageView.setBackgroundColor(Color.RED) , causing an immediate crash with CalledFromWrongThreadException . It explains that this restriction exists because the screen refresh rate (typically 60 Hz) requires UI updates to be fast and thread‑safe; allowing multiple threads to modify the view hierarchy could lead to race conditions and dropped frames.

To understand the root cause, the article traces the call chain from View#setBackgroundColor() to ViewRootImpl#checkThread() . The checkThread() method compares the current thread with the thread stored in ViewRootImpl.mThread , which is set during the construction of ViewRootImpl on the main thread. If they differ, a CalledFromWrongThreadException is thrown.

The analysis continues by exploring how an Activity’s top‑level view (the DecorView ) is created. It follows the flow from Activity#setContentView() to PhoneWindow#setContentView() , then to PhoneWindow#installDecor() , where a DecorView and its content parent are generated. The DecorView is ultimately added to the window manager via WindowManagerImpl#addView() , which creates a ViewRootImpl and calls view.assignParent(this) , establishing the ViewParent relationship.

When a background thread invokes View#requestLayout() , the request propagates up the view hierarchy, eventually reaching ViewRootImpl#requestLayout() . This method calls checkThread() , leading to the exception because the ViewRootImpl was initialized on the main thread.

The article then outlines scenarios where UI updates from a background thread do not cause an exception:

General View solutions: Updating a view before the Activity’s onResume() (when the ViewRootImpl is not yet attached) or calling requestLayout() on the main thread immediately before the background update can bypass the thread check.

Specific View solutions: Certain views, such as ImageView with a ColorDrawable , or TextView with fixed dimensions, may avoid calling requestLayout() and only invoke invalidate() . In hardware‑accelerated mode, invalidate() does not trigger checkThread() , allowing safe background updates.

SurfaceView and TextureView: These views render via their own surface and can be updated from background threads using lockCanvas() without affecting the main view hierarchy.

For view‑specific cases, the article provides code snippets demonstrating how ImageView#setImageDrawable() only calls requestLayout() when the drawable’s intrinsic size changes, and how TextView#checkForRelayout() skips layout requests when the view’s width is fixed and the height does not change.

Finally, the article emphasizes that despite these workarounds, developers should adhere to the main‑thread UI rule because Android’s internal implementations may change, turning such tricks into unstable “time bombs.”