Bug 494223 - Wishlist: More consistent app termination and exception handling on Android
Summary: Wishlist: More consistent app termination and exception handling on Android
Status: REPORTED
Alias: None
Product: kdeconnect
Classification: Applications
Component: android-application (other bugs)
Version First Reported In: unspecified
Platform: Android Android 14.x
: NOR wishlist
Target Milestone: ---
Assignee: Philip C
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-10-06 23:44 UTC by Philip C
Modified: 2024-10-07 04:26 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Philip C 2024-10-06 23:44:20 UTC
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.
Comment 1 Philip C 2024-10-07 04:26:22 UTC
I have removed the word 'crash' from the title. Hopefully this will let the bug janitor stop changing the severity back and forth.