The Window of the Android

The content displayed on an Android phone screen is composed of Windows. The status bar at the top is a Window, the navigation bar at the bottom is a Window, the app display area in the middle is a large Window, and Toast and Dialog have their own Windows. In Android, these Windows are managed through a framework service called WMS (Windows ManagerService). How are these Windows managed and then rendered into a complete display? Let’s talk a little bit about the process.

Briefly understand a few concepts

Window: A display area on the screen that hosts a View. WindowManagerService (WMS) : A service process in the Android framework layer that manages Windows. Surface: Corresponds to a screen buffer, each window corresponds to a Surface. Canvas: Provides a series of drawing interfaces for drawing on the Surface. SurfaceFlinger: An Android service process that manages the Surface.

Position of WMS and SurfaceFlinger in the frame

In the figure below, we can take a look at SurfaceFlinger and WindowManagerService in the Android framework.

WMS and Window

In addition to adding and deleting Windows, WMS also uses a z-order concept to manage the coverage of Windows. Large Z-orders overwrite small ones.

When we create a Window, through WindowManager. LayoutParams type parameter Z – order to set up the Window. Currently defined Z – order value can be in android. The WindowManager class lookup, such as the hierarchy of the status bar is:

/**
 * Window type: the status bar.  There can be only one status bar
 * window; it is placed at the top of the screen, and all other
 * windows are shifted down so they are below it.
 * In multiuser systems shows on all users' windows. */ public static final int TYPE_STATUS_BAR = FIRST_SYSTEM_WINDOW;Copy the code

SurfaceFlinger and Surface

With WMS, we know which Windows are displayed on the current screen, which Windows are hidden, or which Windows are partially obscured. Because each Window corresponds to a value in the screen buffer (Surface). SurfaceFlinger then calculates a buffer value for the current screen based on all existing Surfaces and renders it.

Create a floating View

With that in mind, it’s not hard to make a floating View. As long as we create a Window with a larger Z-order, it’s OK. But this is a sensitive action, such as when a malicious application creates a high-level transparent Window over other trusted applications, then intercepts the click and directs the user to a malicious website. This is called a Tapjacking attack.

So before Android 6.0, if we wanted to create high-level Windows, we would have to declare SYSTEM_ALERT_WINDOW permissions, but this is still not safe, because pre-6.0 permissions are only given at the time of application installation, and most users probably don’t care. Therefore, starting from 6.0, this operation has been made permissions sensitive. Declaring SYSTEM_ALERT_WINDOW will not give you permissions. Instead, an option to allow it to be displayed on top of other applications will appear on the application Settings page. When programming, you must guide the user to manually turn on the switch to be effective.

@TargetApi(Build.VERSION_CODES.M)
public void checkDrawOverlayPermission() {
	if(! Settings.canDrawOverlays(this)) { Intent intent = new Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION, Uri.parse("package:" + getPackageName()));
		startActivityForResult(intent, REQUEST_CODE);
	}
}

@TargetApi(Build.VERSION_CODES.M)
@Override
protected void onActivityResult(int requestCode, int resultCode,  Intent data) {
	if (requestCode == REQUEST_CODE) {
		if (Settings.canDrawOverlays(this)) {
			// continue here - permission was granted
		}
	}
}
Copy the code

Author’s brief introduction Peng Tao (@ Peng Tao me) to make technology to understand and interesting personal blog: http://pengtao.me Jane books: http://www.jianshu.com/u/f9246f41945e making: https://github.com/CPPAlien