SUMMARY We should be consistent when catching exceptions and creating log messages from those exceptions. Add more mechanisms for catching otherwise-uncaught exceptions. Do what we can to show a simple message in the case of catastrophic failure. BACKGROUND When a `Exception` such as `IOException` or `SecurityException` is thrown on Android, we tend to do one of three things: * Catch and suppress the exception * Catch and log the exception to the device's logcat * Ignore the exception and let it bubble up to whatever called our code These correlate roughly to three kinds of situation where something happened that we don't want to happen: * We were doing something that is unreliable (like I/O) * We made an assumption that is invalid in this case (like "a certificate is signed" or "our app is in the foreground") * Android won't let our app do what we ask it to do (like "allocate too much memory" or "dereference null values") SUGGESTION Use consistent formatting for try-catch blocks. That means using the name `ignore` or `ignored` if we don't care about an exception, and a short name like 'ex' if we do. Replace all direct calls to `android.util.Log` with a wrapper such as `SLF4J` or `Timber`. Avoid logging the full stacktraces if they wouldn't help for debugging. For commented-out logs, either delete them or uncomment them + make them log to a deactivated logger. Use consistent log tags instead of a mix of tags (e.g. the Device class should not use both "KDE/Device" and "Device"). Consider matching the guidelines from https://community.kde.org/Guidelines_and_HOWTOs/Debugging/Using_Error_Messages . Be mindful of how logs show up in developer tools like Android Studio and how they would look when copied into a bug report. Add some kind of https://developer.android.com/reference/java/lang/Thread.UncaughtExceptionHandler to each thread we control. Log and/or display a friendly message if the app is about to crash. See if there's a way to have an intermediate step between `KdeConnect::onCreate` and all of the `init`/`initialise*` calls so that we can display a different initial UI (new activity? fragment? dialog? notification?) if there's a serious error during initialisation. Also look at APIs like https://developer.android.com/reference/android/app/ApplicationExitInfo#getTraceInputStream() and maybe show those traces somewhere.
I have removed the word 'crash' from the title. Hopefully this will let the bug janitor stop changing the severity back and forth.