TYPE_APPLICATION_OVERLAY场景下键盘失效及替代方案咨询

Hey there, let’s tackle this frustrating Android O overlay issue you’re dealing with. Starting from Android Oreo (API 26), Google deprecated TYPE_SYSTEM_ALERT and pushed TYPE_APPLICATION_OVERLAY as the replacement for floating windows—but as you’ve noticed, this new overlay type aggressively intercepts input events (like your keyboard and back button) because it’s designed to sit above all other apps.

Here are a few solid alternatives to get your power key functionality working without breaking other input methods:

1. Use AccessibilityService (Recommended) #

Accessibility services are built to listen to system-wide events without needing a floating overlay that steals focus. This is the most reliable approach for capturing power key presses while leaving other inputs intact.

Steps to implement: #

• Create a class extending AccessibilityService:

public class PowerKeyAccessibilityService extends AccessibilityService {
    @Override
    public void onAccessibilityEvent(AccessibilityEvent event) {
        if (event.getEventType() == AccessibilityEvent.TYPE_KEY_EVENT) {
            KeyEvent keyEvent = (KeyEvent) event.getParcelableData();
            if (keyEvent.getAction() == KeyEvent.ACTION_DOWN && keyEvent.getKeyCode() == KeyEvent.KEYCODE_POWER) {
                // Your power key functionality here
                Log.d("PowerKey", "Power key pressed!");
            }
        }
    }

    @Override
    public void onInterrupt() {
        // Handle service interruptions
    }
}

• Declare the service in your AndroidManifest.xml with the necessary permissions and configuration:

<service
    android:name=".PowerKeyAccessibilityService"
    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>

• Create res/xml/accessibility_service_config.xml to specify event types to listen for:

<accessibility-service xmlns:android="http://schemas.android.com/apk/res/android"
    android:accessibilityEventTypes="typeKeyEvent"
    android:accessibilityFeedbackType="feedbackGeneric"
    android:accessibilityFlags="flagDefault"
    android:description="@string/accessibility_service_description" />

• Don’t forget to add a description string in strings.xml explaining why your app needs this permission—users will see it when enabling the service.

Pros: No overlay needed, doesn’t block other inputs, reliable event capture.
Cons: Requires users to manually enable accessibility permissions for your app.

2. Use DeviceAdminReceiver (For Enterprise/Trusted Apps) #

If your app is intended for enterprise use or you can get users to grant device admin rights, this approach lets you listen to power key events at the system level.

Steps to implement: #

• Create a class extending DeviceAdminReceiver:

public class PowerKeyDeviceAdminReceiver extends DeviceAdminReceiver {
    @Override
    public void onKeyguardShown(Context context, Intent intent) {
        // This triggers when the power key is pressed (since it usually turns on the keyguard)
        // Your functionality here
    }

    @Override
    public void onScreenOff(Context context, Intent intent) {
        // Alternatively, listen for screen off events triggered by the power key
    }
}

• Declare the receiver in AndroidManifest.xml:

<receiver
    android:name=".PowerKeyDeviceAdminReceiver"
    android:permission="android.permission.BIND_DEVICE_ADMIN">
    <meta-data
        android:name="android.app.device_admin"
        android:resource="@xml/device_admin_config" />
    <intent-filter>
        <action android:name="android.app.action.DEVICE_ADMIN_ENABLED" />
        <action android:name="android.intent.action.SCREEN_OFF" />
        <action android:name="android.intent.action.KEYGUARD_SHOWN" />
    </intent-filter>
</receiver>

• Create res/xml/device_admin_config.xml:

<device-admin xmlns:android="http://schemas.android.com/apk/res/android">
    <uses-policies>
        <watch-login />
    </uses-policies>
</device-admin>

• You’ll need to prompt users to activate device admin for your app via DevicePolicyManager.

Pros: High-level system access, no overlay interference.
Cons: Users may be wary of granting device admin rights (it’s a powerful permission), not ideal for consumer apps.

3. Adjust Overlay Window Flags (If You Must Keep the Overlay) #

If you absolutely need to use an overlay, you can tweak its window flags to prevent it from stealing focus and blocking other inputs. Note that this won’t let you directly capture power key presses via the overlay—you’ll need to combine it with a BroadcastReceiver listening for screen events.

Update your overlay params: #

WindowManager.LayoutParams params = new WindowManager.LayoutParams(
    WindowManager.LayoutParams.WRAP_CONTENT,
    WindowManager.LayoutParams.WRAP_CONTENT,
    Build.VERSION.SDK_INT >= Build.VERSION_CODES.O ?
        WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY :
        WindowManager.LayoutParams.TYPE_SYSTEM_ALERT,
    // Add these flags to avoid blocking inputs
    WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE |
    WindowManager.LayoutParams.FLAG_NOT_TOUCH_MODAL |
    WindowManager.LayoutParams.FLAG_LAYOUT_IN_SCREEN,
    PixelFormat.TRANSLUCENT
);

• Then, register a broadcast receiver to listen for ACTION_SCREEN_OFF or ACTION_SCREEN_ON events triggered by the power key:

public class PowerKeyBroadcastReceiver extends BroadcastReceiver {
    @Override
    public void onReceive(Context context, Intent intent) {
        if (Intent.ACTION_SCREEN_OFF.equals(intent.getAction())) {
            // Power key was pressed to turn off the screen
            // Your functionality here
        }
    }
}

Pros: Keeps your overlay intact.
Cons: Only detects screen state changes, not the exact moment the power key is pressed (you can’t distinguish between power key presses and automatic screen timeout).

内容的提问来源于stack exchange，提问作者Ayush Kshitij