Someone had a shortcut with the trigger ad that expanded to their full postal address. It worked exactly as designed, including in the middle of the word "address", which is how they discovered it.
That is funny once. What is not funny is that the same class of mistake, with a different trigger, quietly rewrites a word in a message you have already sent.
When is a trigger a trigger
The app sees characters arriving in a field. It has to decide, on each change, whether the recent characters constitute a trigger the user meant to fire.
The naive rule — does the text end with a known trigger — is what produced the ad problem. It fires on any word containing the trigger at its end, which includes a lot of ordinary words.
The next rule — the trigger must be preceded by a word boundary — is better and still wrong for Korean. Hangul does not have the same relationship between characters and word boundaries that Latin script does, and a boundary rule tuned for spaces and punctuation behaves differently in a language where a particle attaches directly to a noun.
What we do now is a combination:
A trigger must be preceded by a boundary or start of field. Space, punctuation, newline, or nothing.
A trigger must be followed by an explicit end. Expansion fires when you type a terminating character — space, punctuation, or newline — not the instant the trigger's characters exist. This means the trigger is a complete token you finished typing rather than a prefix of a longer word you are still in the middle of.
The terminating character is preserved. Typing ;addr gives you the address followed by the space you typed. Swallowing it forces the user to type it again and feels broken.
A prefixed trigger relaxes the rules. If a trigger starts with a character that does not occur in ordinary writing, the boundary question is much less fraught, which is why we push people towards prefixes.
Undo has to exist
No detection rule is going to be right every time, and the honest response to that is to make being wrong cheap.
Immediately after an expansion, a single action reverts it — the original trigger comes back and the app does not re-expand it. This is a short window, tied to the expansion that just happened.
It exists because the alternative is a user manually deleting a long expanded phrase and retyping the trigger they wanted to keep as literal text, which is slower than not having the app at all. It also makes aggressive trigger design safe to experiment with: you can try a shorter trigger knowing that a false fire costs one tap.
What the service can see, and what it does
An accessibility service can read text in other applications. That is what makes the app possible and it is a real grant, so here is a plain statement of what happens with it.
The service receives text change events for editable fields. It examines the tail of the changed text for a match against your trigger list. It holds nothing between events, accumulates no log, keeps no history of what you typed, and stores nothing about field contents. The app has no network access, so there is no path for typed text to leave the device even in principle.
We cannot prove this to you from outside the app. What we can say is that this is the design, and that the absence of network permission is a structural constraint rather than a promise about behaviour.
More generally: an accessibility service is one of the most powerful things you can grant on Android, plenty of apps ask for it, and the question worth asking each time is what the app does with it and whether it can transmit anything.
Building a library that survives
Start from what you actually repeated. Not what you might need. Look at last week's messages, forms, and chats and find the repeats. It is nearly always: an address, a delivery instruction, bank or account details, a greeting, a closing, the same explanation you have written twenty times, and a polite decline.
Five you remember beat fifty you do not. Recall under pressure is the whole constraint. A library you have to search is a library you will not use, because searching is slower than typing the sentence.
Use one prefix character for everything. A semicolon, a double slash, a full stop. It removes collision as a category of problem and makes every trigger after it short and free.
Group by second character. All addresses starting one way, all support replies another. You are building a small mnemonic system and consistency is what makes it recallable.
Write the phrase in your own voice. Read it aloud before saving. Reusable text that sounds like a form letter gets abandoned, because using it feels worse than typing. A phrase that sounds like you gets used, which is the entire point.
Leave the variable part out. The best expansions carry the stable structure and stop before the specific detail. A support reply with the greeting and the explanation and a gap for the person's name is a good shortcut. One that guesses at the name is a shortcut that requires editing every time, and a shortcut you always edit is barely a shortcut.
Do not shortcut anything that needs judgement. If a message should be different depending on who it is for, the fast version will be sent to the wrong person eventually.
The maintenance nobody does
Shortcuts encode facts, and facts change.
An address shortcut after you move. A phone number after you switch. Bank details after a change. A link after a site reorganises. Business hours after they change. A colleague's name in a template after they leave.
These are worse than having no shortcut, because they are fast, confident, and wrong. You do not proofread an expansion — that is why you made it.
The habit that works: when a fact about you changes, that is the moment to check the library. Not on a schedule. And the app shows when each shortcut was last edited, which is a decent proxy for how likely it is to be stale.
Privacy inside the library itself
The phrase library is on the device and it contains, for most people, some combination of a home address, a phone number, account details, and possibly things that were convenient to save and should not have been.
Bank account numbers are common and are a reasonable thing to store. Passwords, authentication codes, and anything a password manager should hold are not — a phrase library is not a credential store, has none of the protections one has, and an expansion can fire into the wrong field.
If you would not be comfortable with the contents of the library appearing in a text field you did not expect, it should not be in the library.