Crash when inputting the second character in any address field of the composer

[Olf0]

Although there are a couple of older reports WRT crashing composer window, they all seem to be fixed and none seems to be similar.

Expected behavior

Enter addresses successfully in composer window.

Actual behavior

K-9 Mail always crashes, when typing the second character in any address field of the composer window (i.e., To:, CC: and BCC:).

Steps to reproduce

1. Start K-9.
2. Tap on "new email icon": The composer window opens.
3. Tap on an address field and start typing an address: When inputting the second character, K9 crashes.

Environment

• K-9 Mail version: >= 5.200 (or > 5.010), tested with 5.208, 5.400 and 5.403 from F-Droid.
• Android version: AOSP 4.1.2 (API level 16) based Android runtime environment (AlienDalvik) under SailfishOS 2
• Account type (IMAP, POP3, WebDAV/Exchange): IMAP (but seems to be irrelevant)

Logs

• com.fsck.k9_composing-crash_alogcat-mainlog.txt
• com.fsck.k9_composing-crash_alogcat-eventlog.txt

Notes

IIRC K-9 Mail 5.008 was working fine with the same environment and configuration.

[cketti]

Looks like the app is crashing when trying to access the system's contacts provider. Can you provide an unfiltered log containing the stack trace (the lines containing AndroidRuntime)?

[Olf0]

Yes, sure (in the next couple of days).

[Olf0]

Ah, it works, when I let AlienDalvik access the system address book outside the Android container.
K-9 seems to initiate a search in the address book after receiving the second character and crash when nothing is returned (or the intent fails).

But no other Android app (I am using / aware of) crashes in this situation, instead they just allow for manually inputting an (email) address.

[Olf0]

Oh, I can reproduce this crash with K-9 Mail 5.208 on my second ("production") SailfishOS phone (as soon as I turn the contacts access for Android apps off, but I usually have it switched on on this phone).
It must have been K-9 v5.008 with which I remember to have typed addresses manually.

[cketti]

This should be fixed once we switch to runtime permissions. See #2110.

[Olf0]

Thanks for the pointer.

[Olf0]

Still I took a log (as you suggested, hopefully it contains all relevant information), so you can technically confirm your assumption: mainlog_alogcat.txt and eventlog_alogcat.txt
I seem to have opened the composer window 07-13 21:10:14.474 and it crashes 07-13 21:10:25.000 to 07-13 21:10:25.233, AFAICS.

[cketti]

I consider this to be a bug in AlienDalvik. It's not even a SecurityException.

[Olf0]

Well, what difference does it make, if a Security Exception or a regular Exception is thrown?
K-9 could try to catch it, right?

And what else than simply throwing an Exception could AlienDalvik, CyanogenMod, LineageOS and a couple of other "custom ROMs" do, which allow for retracting permissions for a long (i.e., before Google introduced the "runtime permissions API" with API level 26)?

Yes, this issue is not a serious bug, but definitely a usability issue: One observes K-9 Mail to crash without hinting why!
Most users will give up at this point, believing K-9 is broken (and I decided to keep an old K-9 and wait for an eventually fixed version for 1,5 years, before opening this issue). As soon as one understands that the reason for the crash is a retracted permission, it is easy to workaround this be re-granting it (but that is not the point).

Look, K-9 is exceptional (there is no other mobile email client coming close to its rich functionality), thus I and many others depend on it for long. The reason why I still pursue this issue (although I know how to workaround it now), is that IMHO K-9 can easily deliver a good user experience even for the couple of 10000 AlienDalvik users and many 100000 users of aforementioned custom ROMs, if this aspect (i.e., permissions may be retracted under API levels < 26, causing exceptions) is also addressed when dealing with issue #2110.

[cketti]

Throwing such exceptions breaks the API contract. I believe by now most custom ROMs should implement revoking permissions in a compliant way (i.e. if the app doesn't support runtime permissions accessing contacts works and returns an empty contact list; achieves the same, doesn't break apps).

We don't catch unexpected exceptions because then there'd be no way to learn about them. K-9 Mail doesn't contain "phone home" functionality that would allow us to not crash but still learn about the exceptions.

[Olf0]

Throwing such exceptions breaks the API contract.

Sure, without the "Android runtime permissions" (as of API level >= 26), breaking the API contract is a logical consequence of simply retracting a permission, which has been granted upon installation of an app.

I believe by now most custom ROMs [...]

I would expect that to be the case for their releases based on AOSP >= 8.0 (API level >= 26), too.
But that does not imply that everyone can and does switch to such a new version on their devices (I guess that is one of the reasons, why K-9 supports Android versions before 8. ;) ).

We don't catch unexpected exceptions because then there'd be no way to learn about them.

Well, there is a way (actually a beaten path), i.e. via issue reports on Github, see issues #2110 and #3498. ;)
Seriously, you already learnt about the two most prominent ones in issue #2110: Contacts permission and Storage permission.

Side note: Specifically AlienDalvik only allows for retracting the Contacts permission anyway (but globally, for all Android apps, which exacerbates the usability issue, as switching the Contacts permission off is not at all linked to a specific app, e.g. K-9).