AssetManager.update() Loop with Timeout vs. Background finishLoading() Thread: Which Prevents ANR While Showing Progress?

The Recommended Approach

To prevent Application Not Responding (ANR) warnings while maintaining a responsive progress bar, you should periodically call AssetManager.update() within your render loop. You should not offload AssetManager.finishLoading() to a background thread.

Why Background finishLoading() Fails

In libGDX, most asset loaders (especially for textures, meshes, and shaders) must interact with the OpenGL context to upload data to the GPU. Because the OpenGL context is bound to the main render thread, calling finishLoading() on a background thread will typically result in a crash or the creation of "black" textures, as the background thread lacks the necessary GL context. While some data loading happens asynchronously internally, the final GPU upload must occur on the render thread.

Implementation Strategy: Render Loop Update

Using update() is the most reliable way to respect the frame budget because it processes the loading queue incrementally. Each call to update() handles a portion of the queue and then returns control to the render loop, allowing the app to continue drawing the UI and processing input.

Safe Implementation Steps

1. Poll Progress: Call AssetManager.update() once per frame. Use AssetManager.getProgress() to update your progress bar.
2. Handle Completion: update() returns false while assets are still loading and true once the queue is empty.
3. Implement Timeout: Track the elapsed time using a simple timer in your render loop. If the time exceeds your threshold, trigger the cancellation logic.
4. Safe Cancellation: To abort, avoid calling dispose() on individual assets. Instead, use AssetManager.unload() for specific assets or AssetManager.clear() to wipe the queue and loaded assets. This ensures the internal reference counting remains intact.

Comparison Summary

Feature	AssetManager.update()	Background finishLoading()
ANR Risk	Low (Yields every frame)	High (Blocks thread/Crashes GL)
GL Context	Native/Correct	Invalid/Missing
Progress UI	Smooth & Synchronous	Requires Thread Marshaling
Complexity	Low	High (Requires GL sharing)

Assumptions and Limitations

This guidance assumes you are using a standard libGDX setup where the GL context is managed by the AndroidGraphics implementation. Note that while update() prevents the thread from locking, a single exceptionally large asset (e.g., a massive texture) may still cause a momentary frame spike because the GPU upload for a single asset is typically atomic.

Diagnostic Detail Needed: Are you using custom AssetLoader implementations that perform heavy non-GL disk I/O? If so, ensure they implement AsynchronousAssetLoader to keep the I/O off the render thread.