The crash screen should provide the user with the ability to restart the app.

Tasks:

• Record information to build an intent for the app when it crashes
• Add a button below Share Stacktrace which fires the intent to launch the app again
• Finish the crashed activity

I am not sure how this would affect the task-stack. Might need to fiddle with launch options to fix unexpected behaviours.

Jetpack Compose is the next generation UI toolkit for Android. Creating an experimental version of the error screen in compose would serve as a nice playground for the project.

Tasks:

• Setup project for Jetpack Compose (enable compose in build features)
• Create an experimental version of WhatTheStackActivity using composables
• Incorporate Jetpack Compose's Material Theming for implementing dark mode support

The app crashes on startup in the WTS process and I can't initialize the library manually without the content provider because it's annotated with an error and the initializer class is internal 😞

WhatTheStack started as a small project to only display very basic information on a crash. findViewById sufficed for this purpose.

However, the complexity of the error screen has increased since then, and is going to continue in that direction. Therefore it makes sense to now refactor the project to migrate to ViewBinding instead.

Tasks:

• Enable ViewBinding in the project's build configuration
• Migrate to ViewBinding in the sample app
• Migrate to ViewBinding in the library

When app crashes with a really large exception (such as stack overflow error with a really long stack trace), WhatTheStack will crash:

kotlinx.coroutines.CoroutinesInternalError: Fatal exception in coroutines machinery for CancellableContinuation(DispatchedContinuation[AndroidUiDispatcher@491392b, Continuation at androidx.compose.runtime.PausableMonotonicFrameClock.withFrameNanos(PausableMonotonicFrameClock.kt:63)@382a188]){Completed}@3066721. Please read KDoc to 'handleFatalException' method and report this incident to maintainers
	at kotlinx.coroutines.DispatchedTask.handleFatalException(DispatchedTask.kt:144)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:115)
	at androidx.compose.ui.platform.AndroidUiDispatcher.performTrampolineDispatch(AndroidUiDispatcher.android.kt:81)
	at androidx.compose.ui.platform.AndroidUiDispatcher.access$performTrampolineDispatch(AndroidUiDispatcher.android.kt:41)
	at androidx.compose.ui.platform.AndroidUiDispatcher$dispatchCallback$1.doFrame(AndroidUiDispatcher.android.kt:68)
	at [android.view.Choreographer$CallbackRecord.run(Choreographer.java:1035)](http://android.view.Choreographer$CallbackRecord.run(Choreographer.java:1035))
	at [android.view.Choreographer.doCallbacks(Choreographer.java:845)](http://android.view.Choreographer.doCallbacks(Choreographer.java:845))
	at [android.view.Choreographer.doFrame(Choreographer.java:775)](http://android.view.Choreographer.doFrame(Choreographer.java:775))
	at [android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1022)](http://android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1022))
	at [android.os.Handler.handleCallback(Handler.java:938)](http://android.os.Handler.handleCallback(Handler.java:938))
	at [android.os.Handler.dispatchMessage(Handler.java:99)](http://android.os.Handler.dispatchMessage(Handler.java:99))
	at [android.os.Looper.loopOnce(Looper.java:201)](http://android.os.Looper.loopOnce(Looper.java:201))
	at [android.os.Looper.loop(Looper.java:288)](http://android.os.Looper.loop(Looper.java:288))
	at [android.app.ActivityThread.main(ActivityThread.java:7840)](http://android.app.ActivityThread.main(ActivityThread.java:7840))
	at java.lang.reflect.Method.invoke(Native Method)
	at [com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:550)](http://com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:550))
	at [com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)](http://com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003))
Caused by: android.os.TransactionTooLargeException: data parcel size 7859848 bytes
	at android.os.BinderProxy.transactNative(Native Method)
	at [android.os.BinderProxy.transact(BinderProxy.java:571)](http://android.os.BinderProxy.transact(BinderProxy.java:571))
	at [android.os.IMessenger$Stub$Proxy.send(IMessenger.java:125)](http://android.os.IMessenger$Stub$Proxy.send(IMessenger.java:125))
	at [android.os.Messenger.send(Messenger.java:59)](http://android.os.Messenger.send(Messenger.java:59))
	at com.haroldadmin.whatthestack.WhatTheStackExceptionHandler.uncaughtException(WhatTheStackExceptionHandler.kt:22)
	at [java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1073)](http://java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1073))
	at [java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1068)](http://java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1068))
	at kotlinx.coroutines.CoroutineExceptionHandlerImplKt.handleCoroutineExceptionImpl(CoroutineExceptionHandlerImpl.kt:45)
	at kotlinx.coroutines.CoroutineExceptionHandlerKt.handleCoroutineException(CoroutineExceptionHandler.kt:39)
	at kotlinx.coroutines.StandaloneCoroutine.handleJobException(Builders.common.kt:192)
	at kotlinx.coroutines.JobSupport.finalizeFinishingState(JobSupport.kt:229)
	at kotlinx.coroutines.JobSupport.tryMakeCompletingSlowPath(JobSupport.kt:906)
	at kotlinx.coroutines.JobSupport.tryMakeCompleting(JobSupport.kt:863)
	at kotlinx.coroutines.JobSupport.makeCompletingOnce$kotlinx_coroutines_core(JobSupport.kt:828)
	at kotlinx.coroutines.AbstractCoroutine.resumeWith(AbstractCoroutine.kt:100)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:46)
	at kotlinx.coroutines.UndispatchedCoroutine.afterResume(CoroutineContext.kt:147)
	at kotlinx.coroutines.AbstractCoroutine.resumeWith(AbstractCoroutine.kt:102)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:46)
	at kotlinx.coroutines.internal.ScopeCoroutine.afterResume(Scopes.kt:33)
	at kotlinx.coroutines.AbstractCoroutine.resumeWith(AbstractCoroutine.kt:102)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:46)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104)

Even worse, this exception will override original exception, making it unaccessible unless I disable WhatTheStack.

Maybe in this rare case, WhatTheStack could try catch this error, print original exception to the logcat and just display the message (without the stacktrace)?

Hey,

We're seeing a crash in our debug and release builds with the below stacktrace. The behaviour is strange because the app technically crashes but because the service is going into a fatal state, we just get a dialog to state that this app keeps stopping etc.

I believe it's a race condition issue because when I attach a debugger to sanity check the pid, I can't reproduce the issue. Removing WhatTheStack also resolves it but I'd like to see what I can do to work around this.

When our app starts, our Application will create our Dagger AppModule which includes getting our encrypted realm instance. From your experience with Jetpack Startup, do you believe it would be better for us to adapt it to hopefully prevent this issue?

Hi,

Great idea with the library! Unfortunately I cannot make it work on minified builds: the Service simply doesn't get the message to start the Activity. I can reproduce the issue by building the release variant of the demo app in this repository, without modifying anything. Devices: OnePlus 3T (Android 9), Galaxy Note 10+ (Android 10)

I've spent some time trying to fix this as I'm working on something similar, but couldn't make it work. I tried starting the service in different ways (starting the Activity in onStartCommand()) which, again, works in debug builds but not after enabling minification. @Keep-ing every relevant class didn't fix the issue either.

Is there a limitation regarding ProGuard I wasn't aware of?

Thanks, Peter

If you register a custom UncaughtExceptionHandler you should delegate to the currently set default UncaughtExceptionHandler. This allows for chaining of multiple different UncaughtExceptionHandlers, e.g. WhatTheStack and Crashlytics.

To support users of the library who are targeting SDK 12/S/31 or higher, please add android:exported="true|false" in AndroidManifest.xml for these components:

com.haroldadmin.whatthestack.WhatTheStackService com.haroldadmin.whatthestack.WhatTheStackActivity

Currently the only way to get my app to build with targetSdkVersion 31 is to add mergeable entries for these components in my app's Manifest with android:exported="true" to overwrite the library manifest entries i.e.

<service
          android:name="com.haroldadmin.whatthestack.WhatTheStackService"
          android:process=":what_the_stack_process"
          android:exported="false"
          tools:node="merge"/>
<activity
          android:name="com.haroldadmin.whatthestack.WhatTheStackActivity"
          android:process=":what_the_stack_process"
          android:exported="true"
          tools:node="merge"/>

see https://developer.android.com/about/versions/12/behavior-changes-12#exported

Without this my app consistently crashes due to the class being discarded by R8.

 D  Shutting down VM
 E  FATAL EXCEPTION: main
 E  Process: dev.msfjarvis.aps, PID: 2800
 E  java.lang.RuntimeException: Unable to get provider androidx.startup.InitializationProvider: androidx.startup.StartupException: java.lang.ClassNotFoundException: com
    .haroldadmin.whatthestack.WhatTheStackInitializer
 E      at android.app.ActivityThread.installProvider(ActivityThread.java:7135)
 E      at android.app.ActivityThread.installContentProviders(ActivityThread.java:6675)
 E      at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6592)
 E      at android.app.ActivityThread.access$1300(ActivityThread.java:233)
 E      at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1896)
 E      at android.os.Handler.dispatchMessage(Handler.java:106)
 E      at android.os.Looper.loop(Looper.java:223)
 E      at android.app.ActivityThread.main(ActivityThread.java:7523)
 E      at java.lang.reflect.Method.invoke(Native Method)
 E      at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
 E      at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:941)
 E  Caused by: androidx.startup.StartupException: java.lang.ClassNotFoundException: com.haroldadmin.whatthestack.WhatTheStackInitializer
 E      at androidx.startup.InitializationProvider.onCreate(InitializationProvider.java:22)
 E      at android.content.ContentProvider.attachInfo(ContentProvider.java:2388)
 E      at android.content.ContentProvider.attachInfo(ContentProvider.java:2358)
 E      at android.app.ActivityThread.installProvider(ActivityThread.java:7130)
 E      ... 10 more
 E  Caused by: java.lang.ClassNotFoundException: com.haroldadmin.whatthestack.WhatTheStackInitializer
 E      at java.lang.Class.classForName(Native Method)
 E      at java.lang.Class.forName(Class.java:454)
 E      at java.lang.Class.forName(Class.java:379)
 E      at androidx.startup.InitializationProvider.onCreate(InitializationProvider.java:18)
 E      ... 13 more
 E  Caused by: java.lang.ClassNotFoundException: com.haroldadmin.whatthestack.WhatTheStackInitializer
 E      ... 17 more

Hey! Thank you for this library. I just got it up and running and we're excited to catch those rare but annoying to debug crashes when away from our machines. I implemented it (0.3.0) into our existing project and had to make two changes to our codebase:

• Add Configuration.Provider interface for WorkManager in the main application, as we provide Workmanager through Dagger WorkManager.getInstance(applicationContext).
• Add the following block of code in the Application onCreate:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.P) {
    if (packageName != getProcessName()) WebView.setDataDirectorySuffix(getProcessName())
}

The second fix was a result of whatthestack throwing the following exception:

  
  2021-12-03 23:59:10.482 17446-17446/com.myapp.name.dev E/AndroidRuntime: FATAL EXCEPTION: main
    Process: com.myapp.name.dev:what_the_stack_process, PID: 17446
    java.lang.RuntimeException: Unable to create application com.myapp.name.DebugApplication: java.lang.RuntimeException: Using WebView from more than one process at once with the same data directory is not supported. https://crbug.com/558377
        at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6465)
        at android.app.ActivityThread.access$1300(ActivityThread.java:219)
        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1859)
        at android.os.Handler.dispatchMessage(Handler.java:107)
        at android.os.Looper.loop(Looper.java:214)
        at android.app.ActivityThread.main(ActivityThread.java:7356)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:930)
     Caused by: java.lang.RuntimeException: Using WebView from more than one process at once with the same data directory is not supported. https://crbug.com/558377
        at org.chromium.android_webview.AwBrowserProcess.a(PG:40)
        at kv.c(PG:90)
        at kv.b(PG:160)
        at kv.e(PG:177)
        at com.android.webview.chromium.WebViewChromiumFactoryProvider.getStatics(PG:204)
        at android.webkit.WebView.setWebContentsDebuggingEnabled(WebView.java:1974)
        at com.myapp.name.DebugApplication.onCreate(DebugApplication.kt:17)
        at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1182)
        at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6460)
        at android.app.ActivityThread.access$1300(ActivityThread.java:219) 
        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1859) 
        at android.os.Handler.dispatchMessage(Handler.java:107) 
        at android.os.Looper.loop(Looper.java:214) 
        at android.app.ActivityThread.main(ActivityThread.java:7356) 
        at java.lang.reflect.Method.invoke(Native Method) 
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492) 
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:930) 

I don't see any webview code in this repo, so I assume it's down to us having multiple webviews (and could be fixed by removing WebView.setWebContentsDebuggingEnabled). Happy to close this issue out as it could help others with the same issue.

It is helpful to view the stacktraces of all active threads during the time an exception is thrown. Representing each thread's stacktrace in a list of collapsible items would make it easy to go through each one of them.

Tasks:

• Capture all active stacktraces using the Thread.getAllStackTraces() API in the exception handler
• Parse the captured values and send them over the service connection
• Create an accordion-style list to display the stacktrace of each thread

This is a fairly huge change. Discussing exact UI implementations would be helpful before starting work on the PR.

The current error reporting screen supports both light and dark themes, using the Material Components library. It would be great if we could provide more customization options to the user in the form of additional themes.

Tasks:

• Add additional themes to styles.xml
• Make themes configurable through application code, or manifest merger (needs exploration)
• Perform a check in WhatTheStackActivity to decide which theme to use

The library relies on a service running in a different process to process and display the error screen. This means that if the application crashes immediately after start, the service might not get enough time to be prepared for accepting new messages.

Unfortunately it looks like there is no easy solution for this problem.

This library consists of two parts: A background service, and a UI Activity. Consider separating them into different modules and allow more flexibility between them.

Separating these classes will allow for features such as:

• Adding custom exception handlers
• Showing a different Activity when the app crashes
• Selectively including only the required dependencies in projects

This library is incredibly awesome, it's a tiny idea that can dramatically improve developing experience.

I haven't had the pleasure yet to test and use it yet but I can tell you a couple of ideas that came to my mind (Maybe with time I can create a pr and add them)

Instead of exception, cause, message thrown, a RecyclerView listing an icon together with the title, and a content TextView for each field could be used, so you have nicer animations, better graphic and higher flexibility (If one day you want to add another field to show).

Plus, you could add a "Share Logcat" button alongside "Copy Logcat", to provide more options.