Why Android clipboard apps can't watch your clipboard

On a Mac or a Windows PC, a clipboard manager has a simple job. Something changes on the clipboard, the app saves it. That is the whole trick, and it is why desktop clipboard managers feel invisible.

On Android, that trick has been off the table since Android 10. Building Clypy for Android meant working out what is still allowed, building around it, and being honest about the parts that still do not work as well as we would like. This post covers all three.

The rule

Google's Android 10 privacy changes put it in one sentence:

Unless your app is the default input method editor (IME) or is the app that currently has focus, your app cannot access clipboard data on Android 10 or higher.

Before Android 10, a clipboard app could run a background service, listen for clipboard changes and save every one. That stopped working. An app in the background can no longer read the clipboard at all.

It is a good rule. Your clipboard sees passwords, one-time codes, addresses and private messages, and any app you had installed could quietly read all of it. We would rather build around the rule than wish it away.

What that leaves a clipboard app

The sentence above leaves exactly two ways in. Either your app is the one on screen, or it is the keyboard. Android's share sheet adds a third: the user can hand something to an app on purpose.

So Clypy captures in three ways on Android:

1. Opening the app. While Clypy is on screen, it can read the clipboard like any other app in focus.
2. The share sheet. Share text or an image to Clypy from any app.
3. The Clypy keyboard. This is the one that does most of the work, and the rest of this post is mostly about it.

Some Android apps read the screen through an accessibility service instead. We do not. That permission exists to help people with disabilities use their phones, and it can see everything on the screen, which is far more than a clipboard app should ask for.

Why the keyboard

A keyboard is an input method, and the active input method is the one background component Android still lets read the clipboard. Making Clypy a keyboard is not a workaround in the sneaky sense. It is the route Android leaves open.

The rule says the default input method, not the keyboard on screen. Android tells the keyboard you have chosen about every copy, whether or not it is showing. So while Clypy is the selected keyboard, it saves each copy as you make it, in any app, even with the keyboard hidden. If the keyboard is up when you copy, the clip appears in it immediately. You can turn the hidden part off in Clypy's keyboard settings ("Save while hidden").

That leads to the first honest limit. While Clypy is the selected keyboard, everything you copy gets saved. Clypy pastes but does not type, so most people type with Gboard and switch to Clypy only to paste. In that case Gboard is the default input method, so Clypy hears nothing until it appears. Then it saves whatever is on the clipboard at that moment: your latest copy, not the three before it.

Either way, Clypy skips anything the copying app marks as sensitive. Password managers and banking apps set that flag (Android 13 added a standard one), and since a keyboard cannot see which app made a copy, the flag is what Clypy goes by.

The second limit is images. When another app copies an image, the clipboard holds a link to that app's content, and the app copying it decides who may read it. Often the keyboard is not allowed to, so the image never arrives. The share sheet does not have this problem, so for images, sharing to Clypy is the reliable route.

Getting a clip off the phone without opening the app

Saving a clip is half the job. It also has to reach your other devices, and the keyboard is a poor place to run a sync engine. It runs in its own process, Android can shut it down the moment you dismiss it, and porting our whole sync protocol into it would mean maintaining a second copy of the hardest code we have.

Our first version did the obvious thing: the keyboard saved the clip and left syncing to the app. The problem is that you might not open the app for days, so a clip copied on your phone could sit there for days too.

What we built instead is small. The keyboard encrypts the clip and saves it to the same local database the app uses. Then it sends that one change, signed with the device's key, to our relay over HTTPS. The relay checks the signature and passes the encrypted change to any of your paired devices that are online. It does not store it. Your laptop receives the clip a moment after you copied it on your phone, and the Clypy app never had to open.

Three things went wrong on the way, and they are the kind of thing that only shows up on real devices:

• The upload got killed halfway. We first sent the clip from a background thread. Android treats a keyboard's process as disposable once the keyboard is hidden, so the thread was routinely killed mid-upload. The clip was saved, but nothing was sent. The fix was to hand the upload to WorkManager, Android's scheduler for work that has to finish, with a retry if the network drops.
• The scheduler was not there. WorkManager only starts up in an app's main process, and the keyboard runs in a separate one. Scheduling the upload from the keyboard silently did nothing. The fix was a configuration setting that lets the keyboard's process schedule work for the main process to run.
• Android 12 and earlier lack the signing algorithm. The relay checks an Ed25519 signature, and Android's built-in cryptography only includes Ed25519 from Android 13. Rather than bundle a crypto library into the keyboard, on Android 12 and earlier the keyboard skips the upload and the clip syncs the next time the app runs.

One rule held throughout: a change is only marked as sent once one of your devices has taken it. If the phone loses signal or Android kills the process, nothing is lost. The relay keeps nothing, so if none of your other devices is online, it has nowhere to send the clip; the phone tries again over the next hour, and again with every copy after that, or the app sends it when it next opens.

The direction we have not solved: clips coming to the phone

Going the other way is harder. When you copy something on your laptop, your phone receives it while the Clypy app is open, or when Android runs a background sync. Clypy asks for one every 15 minutes, the shortest interval Android allows. Android treats that as a request, not a promise: it decides when to run based on battery, network and how often you use the app, and some phone makers' battery savers delay it further.

Nothing wakes the phone the moment you copy on your laptop. The usual way to do that on Android is a push message through Google's Firebase Cloud Messaging, which needs a server to keep a token for each of your devices. Our relay keeps nothing in storage today, so adding that would change how it works, and we have not done it.

In practice, if a clip from your computer is not in the keyboard yet, open the Clypy app for a second. It syncs as soon as it is on screen.

What this means if you use Clypy on Android

• Use the Clypy keyboard as your everyday keyboard if you want every copy saved without thinking about it.
• Share images to Clypy rather than copying them.
• On Android 13 and later, clips saved on your phone reach your computer straight away. On Android 12 and earlier they go the next time you open the app.
• For clips coming from your computer, open the app for a moment if one has not arrived.
• If your phone's maker is aggressive about battery, exclude Clypy from battery optimization. The menu names vary by manufacturer.

Sync and the Android keyboard are part of Clypy Pro. Local history on each device is free.

The rule makes clipboard apps harder to build, and it means Clypy on Android asks a little more of you than Clypy on a desktop. We still think Google made the right call. (The iPhone is stricter still; we wrote about how Clypy works on iOS too.) If you want to set up the phone side, our guides cover Android and Windows and Android and a Mac, including the free options that do not involve us.