Hey there! I’ve tackled similar Android input monitoring scenarios before, so let’s break down exactly how you can listen to every key press—even from default or third-party keyboards—in your Service, plus the critical system constraints you need to keep in mind.

This is the only legal and stable way to listen to cross-app input events (including those from default keyboards) on Android. Regular Services can’t access input focus from other apps, but Accessibility Services are system-designed components for assistive features that are granted permission to monitor UI interactions and input events.

Step-by-Step Implementation #

1. Create an Accessibility Service Subclass #

Extend AccessibilityService and override core methods to capture input events:

class KeyListenerAccessibilityService : AccessibilityService() {
    override fun onAccessibilityEvent(event: AccessibilityEvent) {
        // Listen for text input changes (covers soft keyboard input)
        if (event.eventType == AccessibilityEvent.TYPE_VIEW_TEXT_CHANGED) {
            val inputText = event.text?.toString() ?: ""
            // Pass this input to your background Service (e.g., via LocalBroadcast or bound Service)
            Log.d("KeyListener", "Detected text input: $inputText")
            // Note: You'll get the updated text, not individual key presses (e.g.,联想输入"king" will return "king" directly)
        }

        // Listen for physical key presses (volume, back, etc.)
        else if (event.eventType == AccessibilityEvent.TYPE_VIEW_KEY_EVENT) {
            val keyEvent = event.parcelableData as? KeyEvent
            keyEvent?.let {
                if (it.action == KeyEvent.ACTION_DOWN) {
                    val keyChar = it.displayLabel
                    val keyCode = it.keyCode
                    Log.d("KeyListener", "Physical key pressed: $keyChar (code: $keyCode)")
                }
            }
        }
    }

    override fun onInterrupt() {
        // Clean up resources if the service is interrupted
    }
}

2. Declare the Service in Your Manifest #

Add the required permission and service declaration, plus link to a configuration file:

<uses-permission android:name="android.permission.BIND_ACCESSIBILITY_SERVICE" />

<application ...>
    <service
        android:name=".KeyListenerAccessibilityService"
        android:permission="android.permission.BIND_ACCESSIBILITY_SERVICE">
        <intent-filter>
            <action android:name="android.accessibilityservice.AccessibilityService" />
        </intent-filter>
        <meta-data
            android:name="android.accessibilityservice"
            android:resource="@xml/accessibility_service_config" />
    </service>
</application>

3. Create the Accessibility Service Configuration File #

Make a file at res/xml/accessibility_service_config.xml to define your service’s scope and permissions:

<?xml version="1.0" encoding="utf-8"?>
<accessibility-service xmlns:android="http://schemas.android.com/apk/res/android"
    android:accessibilityEventTypes="typeViewTextChanged|typeViewKeyEvent"
    android:accessibilityFeedbackType="feedbackGeneric"
    android:accessibilityFlags="flagDefault|flagIncludeNotImportantViews"
    android:canRetrieveWindowContent="true"
    android:description="@string/accessibility_service_desc" />

Don’t forget to add a clear description in strings.xml (users will see this when enabling the service, e.g., "Monitors input events to support [your app's feature]").

Critical Caveats #

• User Manual Authorization: Accessibility Services require users to manually enable them in the system’s "Accessibility Settings". You can guide users to this page with:

  fun openAccessibilitySettings(context: Context) {
      val intent = Intent(Settings.ACTION_ACCESSIBILITY_SETTINGS)
      context.startActivity(intent)
  }
  

• Privacy Restrictions: Android 10+ automatically blocks events from sensitive input fields (like password boxes). You won’t be able to capture these inputs—this is a non-negotiable system privacy safeguard.
• Compliance: Don’t overuse this service. Google Play may reject apps that misuse Accessibility Services for non-assistive purposes.

• Regular Services/Broadcasts: These can’t access input focus from other apps, so they can’t capture cross-app key presses.
• Custom IMEs: You already know how to listen to your own keyboard, but default/third-party keyboards are independent IMEs—your app can’t snoop on their events unless you become the active input method (which defeats your goal).
• Root Access: While root lets you listen to system-wide input events, it’s not feasible for most users, breaks app store compliance, and introduces security risks.

If you need to monitor input from default keyboards, Accessibility Service is the only legal, production-ready solution. It requires user authorization, but it’s the system-approved way to do this while respecting privacy rules.

内容的提问来源于stack exchange，提问作者Khalid AL Bitar