Behavior change | Untrusted touch events in Android 12

We have made some changes in Android 12 to improve the security of applications and platforms, so that our users can have a safer experience. To review the article on privacy and security, please see: Policy Update | How Developers Deal with Package Visibility .

Touch control is the main way to interact with applications in the Android system. Additional measures have been taken in Android 12 to ensure that the touch event is correctly delivered to the application that should respond to this event, so as to ensure the intuitiveness and safety of the touch interaction. Specifically, in Android 12, if the touch event is passed from a different application window, the event will be blocked. This change will affect all applications running in Android 12, and has nothing to do with the "targetSdkVersion" of the application. This helps users more intuitively confirm the application they are interacting with. Continue reading this article to see if your app will be affected by this change, and learn how to test your app against this change.

Use Special-Purpose API as much as possible

Before checking whether your application will be affected by this, it is best to evaluate whether the following Android APIs can be used in certain scenarios of your application. These APIs are partly controlled by the system and can be trusted, so you don't need to worry about restrictions on using these APIs. They are:

• Bubbles : Bubbles float on top of other application content like bubbles, and follow the user's location, and can also be expanded to display application functions and information.
• Picture-in-Picture (PIP): The PIP function allows applications to display content in a small window. Users can watch videos through a small window fixed to the corner of the screen, while navigating between applications or browsing the content on the main screen . The user can also drag the PIP window and click on it to expand or close it.
• Notifications : Notifications are messages that Android displays outside of your app’s interface, designed to provide users with reminders, communication information from others, or other timely pop-up information in your app. Users can tap the notification to open the app, or perform operations directly in the notification.
• Snackbars and Toasts : If you need to display a short message in the app, you can use Snackbars. If you need the app to display information in the background, you can see if Toasts meets your needs.

If the usage scenario of your application matches the usage scenario of one of the above APIs, it is strongly recommended that you use these APIs. Not only are these APIs simple and easy to use, they are also more secure, and users are already familiar with most of them.

I be affected?

If your app can't use the above APIs, but let touch events pass directly through its window, then in Android 12 they may not pass to the lower layer as expected. Examples in this regard include but are not limited to the following examples:

• Use FLAG_NOT_TOUCHABLE flag TYPE_APPLICATION_OVERLAY window.
• Use the Activity window FLAG_NOT_TOUCHABLE

If you are using FLAG_NOT_TOUCHABLE , your app may be affected unless your app meets one of the following exemptions:

• Interactions in the application . The overlay will only appear when the user interacts with your app.
• trusted window . These windows include but are not limited to: accessibility window , input method (IME) window and Google Assistant window .
• invisible window . The root view of the window is GONE or INVISIBLE .
• Fully transparent window . The alpha attribute value of the window is 0.0.
• Enough translucent system alarm window . The window is of type TYPE_APPLICATION_OVERLAY, and its alpha value is equal to or less than the value of InputManager.getMaximumObscuringOpacityForTouch() ). This value is currently 0.8 in the developer preview 3 version, but it may change before the final version is released. If there are multiple overlapping windows of this type, their respective opacity values combined to calculate a value as the final result.

If your usage scenario is not included in the above list, then touch events will be blocked. Otherwise, if you want to prevent the delivery of touch events, you can consider deleting the FLAG_NOT_TOUCHABLE flag, and if you want the touch event to penetrate, you can adjust your code to meet one of the above-mentioned situations. Next we will introduce some examples of common patterns that must be changed.

A window with a transparent background and no UI elements

Applications that display certain UI in a window with a transparent background can hide their UI at the view level when appropriate, and add the FLAG_NOT_TOUCHABLE flag so that users can interact with the content of the lower layer.

If like the above picture, the application only hides the UI, either by deleting the sub-views, or changing their visibility (visibility) and adding the FLAG_NOT_TOUCHABLE flag to allow the user to interact with the lower-level view, because the lower-level view Touch events of other apps will be blocked, so this method no longer works on Android 12 (note the difference with the exemption conditions mentioned earlier, here we change the internal view, not the window). In this case, if you want to solve this kind of problem, you can:

• Use WindowManager.removeView() ) to remove the window and pass it to the root view.
• View.setVisibility() on the root view, use View.GONE or View.INVISIBLE make the window invisible.
• Use LayoutParams.alpha make the opacity value of the window 0.0.

Whenever you need to display that interface again, you only need to reverse the above actions.

Unnecessarily large windows

Sometimes the application will want to display some small UI interface and at the same time allow the user to interact with the content of the lower layer of the window. Previously, the application could be implemented by simply using a full-screen window and marking it as FLAG_NOT_TOUCHABLE, as shown in Figure 1:

Please note that in previous operating system versions, touch events through actual UI elements will be passed to the lower window in this case. In this case, please first check whether the Toast API can meet the needs. If not, the solution is also very simple-the picture on the right shows: You only need to reduce the border of the window to the actual UI size , And use FLAG_NOT_TOUCH_MODAL , sometimes you may also need to delete FLAG_NOT_TOUCHABLE .

In this way, touch events outside your UI will penetrate directly to the lower window and will no longer be blocked.

Translucent window

If you use a TYPE_APPLICATION_OVERLAY window and need to allow touch events to penetrate when displaying content, then you must reduce the opacity of the window so that users can reasonably see the UI elements they touch behind the window.

You must window level , just changing the opacity of the view will not work. You can use LayoutParams.alpha to reduce the opacity so that it is lower than or equal to
InputManager.getMaximumObscuringOpacityForTouch() ) value, as shown in the picture on the right. This value is currently 0.8, but it may change before the final version of Android 12 is released.

Now, as long as multiple windows in your app do not overlap each other, touch events will penetrate to the lower window. For more details on overlapping windows, please refer to the FLAG_NOT_TOUCHABLE document.

Accessibility service

When using AccessibilityService (accessibility service), it can create TYPE_ACCESSIBILITY_OVERLAY type windows, these windows are trustworthy, so they can be exempt from some of the restrictions described above. You only need to combine AccessibilityService WindowManager through the getSystemService() method to create the above window.

How to test whether your app is affected

If the system blocks touch operations, Logcat will output the following information:

Untrusted touch due to occlusion by PACKAGE_NAME.

Next

If you want to learn more about untrusted touch events and their exceptions, please refer to the relevant documentation:

• Untrusted touch event
• exception