What would make you trust an Android keyboard with encryption?

The trust model is strong on paper because it removes capability rather than adding promises. No INTERNET permission is the one signal a screenshot cannot fake. The weakness is onboarding. Every proof you listed, reproducible builds, test vectors, permission diffs, is checkable by maybe one install in a thousand. Everyone else falls back to the green shield you are right to distrust. So you have built an evidence chain for auditors and a leap of faith for users, and the two audiences never meet.

I would design onboarding around that gap directly. Do not ask the ordinary user to verify anything. Make verification a visible act that a few competent people perform in public and everyone else inherits. Surface, inside the app, the count of independent rebuilds that matched the published hash for this exact version, linked to who did them. That turns a claim only experts can check into a signal a normal user can read, without pretending they audited it themselves. The failure mode to watch is the first release where nobody reproduces the build in time, because then the shield quietly goes back to meaning trust us.

B first, because it is the only signal on your list I can verify myself in under a minute, and it cheaply rules out the worst outcomes. A is the most persuasive to watch but it proves the demo, not the shipped artifact, so A without D is theatre. What would still stop me is updates. The realistic threat is not version one, it is a later version quietly widening its access once trust is established, so permission diffs surfaced before install plus reproducible builds are the pair that matters, and you need evidence the store artifact matches the audited source, not just that a clean build exists. The other honest blocker is recipient friction. If my contact needs the same tool to read anything I send, convenience beats security for most people within a week. Being explicit about who this is for, high sensitivity use rather than everyday chat, would do more for trust than another badge.

the two-device offline test proves the crypto works, but what about the first key exchange itself - how does device two get the key the very first time, is that pairing step also offline/out-of-band, or does it become the one step people don't think to scrutinize?

Most answers here are attacking the evidence axis, so let me push on the other half of your question - what would still stop me enabling it.

I build a consumer product where people forward their actual phone calls to it (OsmO), so the ask is arguably more invasive than a keyboard. Two things surprised me running that gauntlet.

First: almost nobody verifies. Not "few" - close to zero. We published the evidence and watched the click-through. It is still worth publishing, because the handful who do check are the ones everyone else cites, so evidence works as social proof rather than personal proof. But it does not move installs. If you are tuning the A-E list to convert users, you are tuning the wrong surface.

Second: what actually moved adoption was blast radius and reversibility, not proof. Ordinary users never ask "is this secure." They ask "if you are wrong, what happens to me, and how fast can I undo it." Every point of adoption we gained came from shrinking the answer to that question, not from strengthening the crypto story.

Which leads to the thing that would stop me, and it is a trust-model criticism rather than a cryptographic one: you are asking for 100% of my typing, permanently, in order to secure the ~1% I actually want encrypted. Default keyboard is all-or-nothing and always-on. Even if every one of A-E checks out, the ask is badly matched to the value - I take total permanent exposure for an occasional benefit. "No INTERNET permission" answers "can they exfiltrate." It does not answer "why does this need to sit between me and my banking chat, my work Slack and my password fields in order to encrypt one message to my co-founder."

The version I would enable is the one where the secure surface is not my everyday keyboard - invoked deliberately for the message I am protecting, dormant otherwise. Then exposure matches benefit, and the evidence you publish is defending a much smaller claim, which makes it far easier to believe.

Genuinely unsure on one point though: is always-on default a deliberate bet on the encryption needing to be zero-friction at the moment of typing, or is it a constraint of what Android lets an IME do?

You are worried about the right thing, and since you asked for criticism rather than support, the useful push is on which signal you rank first. The one that matters is not the signal that shows good behavior, it is the signal that removes the ability to misbehave. By that test B beats A. A two device offline demo proves it can work without a network, but not that it will stay off one the moment a network is there. No INTERNET permission is enforced by the platform, not promised by you, so it is the strongest single item on your list. Pair it with D so I can confirm the build I install is the one that was audited, since a permission screen only means something for a binary I can verify.

The honest reason none of these fully close it: a keyboard with no network can still write to local storage, and a companion app that does have network can ship it later. So the trust boundary is not the keyboard alone, it is the keyboard plus everything that can read what it stores. If onboarding names that out loud and shows how you contain it, the security minded people you most want will relax. If it stays quiet on that, they will assume the gap is there, because it usually is.