API handling Android security distance

stay Android In the space of the screen , Most of the areas we can draw at will , Only a part of the area is the fixed content of the display ：

• status bar
• The title bar (ActionBar)
• The page content (Content)
• The navigation bar

The title bar is optional , except Material The application of style is not much , The content of the page is android.R.id.content yes Activity Main content .

And the main thing we need to talk about is Status bar and navigation bar , Because these two areas are in different equipment types , Different Android The size and effect are different for different versions and different manufacturers , wait . These differences undoubtedly increase the complexity of page adaptation , It is also more prone to compatibility problems .
stay 2017 In the second half of iPhone X Release , Liuhaiping equipment is introduced , As a result, big blue and green factories are scrambling to follow suit , At the same time, they have formed their own school , Quite a hundred schools of thought contend .

This has also led to a new problem Fringe area adaptation , At that time Android only 8.1, did not API To support this extra area on the screen , Fortunately, the bangs and the status bar are the same height when most devices are customized .
Finally in the 2018 Published in Android 9 in Google Officially supported liuhaiping , Customized specifications constrain equipment manufacturers , It reduces the difference in the adaptation of the bangs screen , But the root cause has not been solved . Because of the existence of bangs , The page content may be blocked , such as ： Enable page advertising to skip the problem that the button is blocked , The risk of being rejected by the app store .

But fortunately, Android 9 It is required that the fringe equipment must have the following behaviors ：

• An edge can contain at most one bangs .
• A device cannot have more than two bangs .
• There shall be no bangs on the two longer edges of the equipment .
• In vertical screen mode without special signs , The height of the status bar must be equal to the height of the bangs .
• By default , In full screen mode or horizontal screen mode , The entire fringe area must show a black edge .

By default, the fringe height is the same as that of the status bar , So the problem goes back to the status bar area .

Text

So some students must have said ： You can get the height of the status bar directly to adapt to the banged screen . like this ：

val top = context.getStatusBarHeight()
titleBar.setPadding(0, top, 0, 0)

There's nothing wrong with that , In most cases, there is no problem . But now that the official has adapted Liu Haiping , It also provides us with new API Why not ：

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.P) {
    
    window.decorView.post {
    
        val top = window.decorView.rootWindowInsets?.displayCutout?.safeInsetTop ?: 0
        // val bottom = window.decorView.rootWindowInsets?.displayCutout?.safeInsetBottom ?: 0
        titleBar.setPadding(0, top, 0, 0)
    }
}

The above scheme can actually obtain the safety distance in the up, down, left and right directions , But in most cases we just need to deal with the top . In fact, this can solve our problems , But there are better solutions ：

1. Add dependency

implementation 'androidx.core:core:1.7.0'

//  The old version is OK , however getInsets() API  Not added yet 
// implementation 'androidx.core:core:1.3.0'

2. Use ViewCompat Tools

ViewCompat.setOnApplyWindowInsetsListener(titleBar) {
     view: View, insets: WindowInsetsCompat ->
    //val top = insets.systemWindowInsetTop //  The higher version is out of date , You can use the following api Replace 
    val stableInsets = insets.getInsets(
    WindowInsetsCompat.Type.systemBars() or WindowInsetsCompat.Type.displayCutout())
    titleBar.setPadding(0, stableInsets.top, 0, 0)
    return@setOnApplyWindowInsetsListener insets
}

In fact, the screen safety distance , Basically all around this one API,Google It is also recommended that we do this , Its shadow can be seen in many system controls , such as ：AppBarLayout、DrawerLayout、NavigationBarView And so on , The interior is used to handle the system safety distance .

System bar adaptation
As mentioned above, the mobile phone has various system columns （ status bar 、 The navigation bar ）, If a full screen + Hai Ping Liu + Transparent system bar + It is more complicated to deal with these safe distances when the screen rotates , For example, short video pages , Here are a few possible problems ：

• Devices that do not have a navigation bar or can hide the navigation bar dynamically
  Devices that do not rotate the navigation bar （ The navigation bar is always on one side of the screen , Does not follow the screen rotation ）
• A device whose navigation bar rotates with the screen （ Mainly gesture navigation devices and some tablets ）
• Devices with bangs at the bottom of the screen （ The developer option can enable the double bangs mode , There are bangs on both short sides of the equipment ）
• Bottom fringe + Devices displayed with the navigation bar
• … …

All of these questions pass ViewCompat.setOnApplyWindowInsetsListener() To handle it gracefully , adopt WindowInsetsCompat.getInsets(type) You can get the size of each column of the system , We can also get the height of multiple system columns at the same time , The distances are accumulated internally , Return to a similar Rect The object of , Corresponding to the distance between the upper left and lower right of the screen to be inserted ：

val stableInsets = insets.getInsets(
    WindowInsetsCompat.Type.statusBars() or
    WindowInsetsCompat.Type.navigationBars() or
    WindowInsetsCompat.Type.displayCutout())

Then add the corresponding margins to the controls in different positions . In addition to the three types of safety distances mentioned above , There are other types of , Those who are interested can understand .

Other adaptations

ViewCompat.setOnApplyWindowInsetsListener() It can solve the problem of most safe distances , But there's one thing it can't handle , Namely Screen fillets , The calculation of these safe distances does not deal with screen fillets , So if there are fillets to be processed, we have to find another way .
Fortunately Android 12 Support for rounded corners has been officially added in ：

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) {
    
    val roundedCorner = insets.toWindowInsets()
        ?.getRoundedCorner(RoundedCorner.POSITION_TOP_LEFT)
    roundedCorner?.center
}

I used it Pixel4 Real machine discovery can obtain data , But the simulator cannot get .

In addition to fillet support , There is also support for privacy indicators ：

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) {
    
    val rect = insets.toWindowInsets()?.privacyIndicatorBounds
    //  Page controls need to avoid this area , Otherwise it may be covered 
}

Range of privacy indicators , Mainly Camera and microphone Indicator boundaries for in use states , If you are recording a live broadcast or a camera page, you need to deal with this area .

Except for rounded corners , There seems to be no official support for perforated screens , Maybe we will add support for perforated screen later .