Chinese text input silently fails when clipboard writes are denied, preventing fallback

[lihujun101]

Description

ARTEMIS reports successful text input, but the expected Chinese text does not appear in the input field.

Observed on an OPPO PMT110 with ADBKeyboard already enabled.

Evidence

Device logs show the clipboard write being denied:

ClipboardService: op=30 result=false callingPackage=com.artemis.helper

Checking the Helper’s clipboard permission:

adb shell cmd appops get com.artemis.helper WRITE_CLIPBOARD

Returns:

WRITE_CLIPBOARD: foreground; rejectTime=...

Root cause

GestureController.setClipboard() returns true after calling setPrimaryClip() if no exception is thrown. On this device, the system denies the background clipboard write without throwing an exception.

AndroidAdbDriver.input_text() then sends KEYCODE_PASTE and immediately returns success, skipping the ADBKeyboard broadcast fallback.

Test coverage gap

test_set_clipboard_sends_raw_utf8 mocks a successful HTTP response. It verifies UTF-8 request encoding but does not verify an actual clipboard write or cover silent permission denial.

Expected behavior

• Failed text input should not report success.
• Clipboard failures should allow alternative input methods to run.
• Users should not need to modify AppOps permissions manually.

Suggested fix

Try the existing accessibility-based send_text() / ACTION_SET_TEXT path before clipboard injection, checking its return value before falling back.

Also handle silent clipboard write failures so they cannot prematurely terminate the input flow. Add coverage for permission denial, fallback execution, and actual Chinese text entry on a device.