java.util.concurrent.TimeoutException #1146
Description
Device: Samsung Galaxy A16 5G
Android: 16 Beta (SDK 36)
Version: 35 (0.4.0)
Occurred: 33 hours ago with app in foreground
Impact: 1 user, 1 incidence
Exception java.util.concurrent.TimeoutException: com.android.internal.os.BinderInternal$GcWatcher.finalize() timed out after 60 seconds
at java.lang.Daemons$Daemon.isRunning (Unknown Source)
at java.lang.Daemons$FinalizerDaemon.runInternal (Daemons.java:332)
at java.lang.Daemons$Daemon.run (Daemons.java:132)
at java.lang.Thread.run (Thread.java:1119)
Gemini hints:
Gemini may display inaccurate information, so double-check its responses
Summary This crash indicates a TimeoutException occurred during the garbage collection process, specifically when the system attempted to finalize an internal Android object called BinderInternal$GcWatcher. The finalization process, which runs on a dedicated system thread, took longer than 60 seconds to complete for this object. While the stack trace itself points to system daemon threads, the underlying cause is typically within the application's code or a library it uses. This usually means that a finalize() method within the app or a large number of objects requiring finalization are blocking the finalizer thread, preventing timely cleanup and causing the timeout.
Here are 2-3 potential solutions to address this crash:
Avoid or optimize custom finalize() methods: If the application defines its own finalize() methods for resource cleanup, these methods are the primary suspects. The finalize() method is called on a single, dedicated finalizer thread, and if it performs blocking operations, heavy computation, or allocates new objects, it can block the entire finalizer queue and lead to timeouts. It is strongly recommended to manage resource cleanup explicitly using try-with-resources for Closeable objects or by calling explicit close() or release() methods in appropriate lifecycle callbacks (e.g., onDestroy(), onStop()).
Ensure timely release of system resources, especially those involving Binder objects: The BinderInternal$GcWatcher specifically monitors Binder objects, which are fundamental to Android's inter-process communication and system services. This crash suggests the application might be holding onto system service objects (e.g., obtained via Context.getSystemService()) or other components that use Binder IPC, and these objects are not being released or unregistered correctly. For example, LocationManager listeners, SensorManager listeners, MediaRecorder or MediaPlayer instances, or bound Service connections must be explicitly unregistered, released, or unbound when they are no longer needed. This typically occurs in onPause(), onStop(), or onDestroy() of the managing component.
Investigate potential Context or View leaks: Although not a direct finalize() method issue, a Context leak (e.g., holding onto an Activity Context beyond its lifecycle) can indirectly contribute to this problem. Leaked Context objects can maintain references to numerous system services and resources, many of which depend on Binder objects. When these leaked objects finally become eligible for garbage collection, the accumulated finalization work for all their associated system resources can overwhelm the finalizer thread, resulting in a timeout. It is crucial to ensure that Context references are short-lived or to use the Application Context when a longer-lived Context is genuinely required, and to avoid static references to Views or Drawables that hold Context references.