Support for Android

[podusowski]

It is preliminary, i.e. I have only implemented text functions. I have tested in on a toy app (https://github.com/podusowski/endroid), but making workable automated tests on Android is something that needs to be yet explored.

Closes(?) #56

[Gae24]

I tested it a bit and everything seems fine. Do you want to keep working on it?

but making workable automated tests on Android is something that needs to be yet explored.

I think with cargo apk we can run a simple enough app to test all functionalities.

[podusowski]

I have ended up with a separate crate, but it would be nice to have the clipboard crate, which I guess arboard is the closest to being. Would you prefer to have it as a dependency or implemented here directly?

[Gae24]

I think it's fine to leave the implementation inside arboard.
Since recently new methods were added to Get and Set a rebase is necessary.

[complexspaces]

While I'm not against having an Android implementation live inside arboard, I think there's some important questions about guaranteed functionality that need answered before I would commit to maintaining and supporting the functionality. Some of these have been on my mind as well given the WIP iOS backend which has some similar constraints.

My primary concern is around permissions: In modern Android versions the system has gotten fairly picky about when an app can read or modify the clipboard. Does the implementation here minimize prompts like "App accessed the clipboard"?

The restrictions I'm referring to are the bits of documentation spread around ClipboardManager that basically all say the following:

Returns true if there is currently a primary clip on the clipboard. If the application is not the default IME or the does not have input focus this will return false.

I am also aware of the fact that clearing the clipboard only works in the currently-written way when the app is in the foreground/focused, otherwise it silently fails, which might be weird to most users of the crate since things like spawning a background thread to clear the clipboard after a delay won't work all the time.

[wareya]

These are not long-term solvable problems. Clipboard access on secure platforms like ios or android is just always going to suck. Even if you get things sorta working the way they work on desktop right now on ios or android, it's very likely to change in future OS updates and, for example, start spamming the user with "Clipboard accessed!!!" warnings again. Likewise, updates are likely to break any way of getting timered arbitrary clipboard writes (timered clipboard clearing is a special case and if people are using arboard for that then arboard should provide an interface for doing specifically that and it should not block general ios or android support).

As I understand it, right now, projects that use arboard can't even compile on android without special casing all the clipboard stuff with platform-specific cfg directives, even if the clipboard functionality isn't critical. And this has been a reported issue for 3 years (#56) and an actual issue for the entire lifetime of this library.

[podusowski]

My primary concern is around permissions: In modern Android versions the system has gotten fairly picky about when an app can read or modify the clipboard. Does the implementation here minimize prompts like "App accessed the clipboard"?

I admit that my approach was more like a "recon by force", hoping that rough edges are still better than not having it at all. Of course I respect your point of view and I will understand if that it is not good enough to be included in arboard.

For those disappointed, I will leave an (less convenient) alternative - https://crates.io/crates/android_clipboard

[jb55]

I'm getting this after patching egui with this change:

arboard paste error: Unknown error while interacting with the clipboard: JNI call failed

:[

my updated branch is here:

jb55#1

[jb55]

I was able to fix this error on my branch! pasting seems to be working now on android!

[complexspaces]

Hi again everyone, I'd like to followup on my past comments raising maintainability concerns.

I've outlined a plan for the crate in #191 that would alleviate those and make me far more comfortable proceeding with merging Android support for Java-based applications. I wrote some words specifically about Android in the issue as well 😄.

These are not long-term solvable problems. Clipboard access on secure platforms like ios or android is just always going to suck. Even if you get things sorta working the way they work on desktop right now on ios or android, it's very likely to change in future OS updates and, for example, start spamming the user with "Clipboard accessed!!!" warnings again.

As @wareya rightly pointed out, a lot of concerns aren't inherently solvable and just come with using a specific platform. I'm hoping that my current idea of marking Android as "tier 2/3" (TBD, I would welcome suggestions on this) communicates that to end users and sets expectations compared to the easier platforms and consistent APIs arboard has exposed historically.

are likely to break any way of getting timered arbitrary clipboard writes (timered clipboard clearing is a special case and if people are using arboard for that then arboard should provide an interface for doing specifically that and it should not block general ios or android support).

This has been something I've idly considered since 1Password had to internally implement a foreground service for clearing the clipboard. It wouldn't be unfeasible to port that here as its own functionality AFAICT.

As I understand it, right now, projects that use arboard can't even compile on android without special casing all the clipboard stuff with platform-specific cfg directives, even if the clipboard functionality isn't critical. And this has been a reported issue for 3 years (#56) and an actual issue for the entire lifetime of this library.

This is entirely correct, and I appreciate your bluntness. I am in complete agreement that the current state of things is poor and can't continue.

I admit that my approach was more like a "recon by force", hoping that rough edges are still better than not having it at all. Of course I respect your point of view and I will understand if that it is not good enough to be included in arboard.

For those disappointed...

@podusowski In hindsight, I should have been more open to this approach when this PR was first opened, but for personal reasons I wasn't and lacked the capacity to figure out a middleground. As mentioned above, my goal now is to remove all of these stalemates between my intent to keep things "perfect" and lack of time and energy to do that.