Shulou(Shulou.com)06/01 Report--

Today, the editor will share with you the relevant knowledge points about how to use Android SystemBar. The content is detailed and the logic is clear. I believe most people still know too much about this knowledge, so share this article for your reference. I hope you can get something after reading this article. Let's take a look at it.

ROM, remove NavigationBar.

For the resgrep NavigationBar-related res, it is found that the jgrep showNavigationBar-related java can be configured through config_showNavigationBar in framework/base/core/res/res/config.xml, and whether NavigationBar is recorded through the boolean variable mHasNavigationBar in PhoneWindowManager. The specific code is as follows:

MHasNavigationBar = res.getBoolean (com.android.internal.R.bool.config_showNavigationBar)

It is important to note that mHasNavigationBar can also be identified by the Property provided by the system. The specific code is as follows:

String navBarOverride = SystemProperties.get ("qemu.hw.mainkeys")

If ("1" .equals (navBarOverride)) {

MHasNavigationBar = false

} else if ("0" .equals (navBarOverride)) {

MHasNavigationBar = true

}

There is a variable of type WindowState in PhoneWindowManager. MNavigationBar,WindowState is an interface that will be used in PhoneWindowManger prepareAddWindow. Take a closer look at the prepareAddWindowLw method.

Switch (attrs.type) {

Case TYPE_NAVIGATION_BAR:

MContext.enforceCallingOrSelfPermission (android.Manifest.permission.STATUS_BAR_SERVICE, "PhoneWindowManager")

If (mNavigationBar! = null) {

If (mNavigationBar.isAlive ()) {

Return WindowManagerGlobal.ADD_MULTIPLE_SINGLETON

}

}

MNavigationBar = win

MNavigationBarController.setWindow (win)

If (DEBUG_LAYOUT) Slog.i (TAG, "NAVIGATION BAR:" + mNavigationBar)

Break

}

When determining that type is TYPE_NAVIGATION_BAR, assign a value to mNavigationBar, and mNavigationBarController setWindow,mNavigationBarController is a class used to manipulate SystemBar Window. If you are interested, you can take a detailed look at this class, located in / framework/base/services/core/java/com/android/server/policy. If you continue to browse the code, you will find the method layoutNavigationBar, which layout the mNavigationBar through mNavigationBarController.

In framework/base/packages/SystemUI, makeStatusBarView has the following code in PhoneStatusBar:

Try {

Boolean showNav = mWindowManagerService.hasNavigationBar ()

If (DEBUG) Log.v (TAG, "hasNavigationBar=" + showNav)

If (showNav) {

CreateNavigationBarView (context)

}

} catch (RemoteException ex) {

/ / no window manager? Good luck with that

}

Determine whether there is a NavigationBar according to the hasNavigationBar method in WindowManagerService, and then see whether the hasNavigationBar method in PhoneWindowManager is called in WindowMangerService, and the final return is the initial mention of mHasNavigationBar. There are details on how to createAndAddWindows in PhoneStatusBar. If you are interested, you can learn more.

SystemBar Translucent support

Android added two WindowManager.LayoutParams in API 19, namely FLAG_TRANSLUCENT_NAVIGATION and FLAG_TRANSLUCENT_STATUS.

It is mentioned in the official document that when setting FLAG_TRANSLUCENT_NAVIGATION for Window, System UI visibility SYSTEM_UI_FLAG_LAYOUT_STABLE and SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION are automatically set, and when FLAG_TRANSLUCENT_STATUS is set for Window, System UI visibility SYSTEM_UI_FLAG_LAYOUT_STABLE and SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN are automatically set.

Obviously, the System UI visibility has changed at this time, and there is the following code in PhoneWindowManager:

Public int adjustSystemUiVisibilityLw (int visibility) {

MStatusBarController.adjustSystemUiVisibilityLw (mLastSystemUiFlags, visibility)

MNavigationBarController.adjustSystemUiVisibilityLw (mLastSystemUiFlags, visibility)

MRecentsVisible = (visibility & View.RECENT_APPS_VISIBLE) > 0

MTvPictureInPictureVisible = (visibility & View.TV_PICTURE_IN_PICTURE_VISIBLE) > 0

/ / Reset any bits in mForceClearingStatusBarVisibility that

/ / are now clear.

MResettingSystemUiFlags & = visibility

/ / Clear any bits in the new visibility that are currently being

/ / force cleared, before reporting it.

Return visibility &-mResettingSystemUiFlags

&-- mForceClearedSystemUiFlags

}

You can see that the Controller that controls SystemBar mentioned earlier plays a role at this time, calls its adjustSystemUiVisibilityLw, and continues to look at the relevant code in BarController.

Public void adjustSystemUiVisibilityLw (int oldVis, int vis) {

If (mWin! = null & & mTransientBarState = = TRANSIENT_BAR_SHOWING & & (vis & mTransientFlag) = = 0) {

/ / sysui requests hide

SetTransientBarState (TRANSIENT_BAR_HIDING)

SetBarShowingLw (false)

} else if (mWin! = null & & (oldVis & mUnhideFlag)! = 0 & & (vis & mUnhideFla = = 0) {

/ / sysui ready to unhide

SetBarShowingLw (true)

}

}

At the same time, we see that there is applyTranslucentFlagLw in BarController. By looking for its calling place, we find that it is still called in PhoneWindowManager. Here is the calling part.

/ / apply translucent bar vis flags

WindowState fullscreenTransWin = isStatusBarKeyguard () & &! mHideLockScreen? MStatusBar: mTopFullscreenOpaqueWindowState

Vis = mStatusBarController.applyTranslucentFlagLw (fullscreenTransWin, vis, oldVs)

Vis = mNavigationBarController.applyTranslucentFlagLw (fullscreenTransWin, vis, oldVis)

Final int dockedVis = mStatusBarController.applyTranslucentFlagLw (mTopDockedOpaqueWindowState, 0,0)

Final boolean fullscreenDrawsStatusBarBackground =

(drawsSystemBarBackground (mTopFullscreenOpaqueWindowState) & & (vis & View.STATUS_BAR_TRANSLUCENT) = = 0) | | forcesDrawStatusBarBackground (mTopFullscreenOpaqueWindowState)

Final boolean dockedDrawsStatusBarBackground = (drawsSystemBarBackground (mTopDockedOpaqueWindowState) & & (dockedVis & View.STATUS_BAR_TRANSLUCENT) = = 0) | | forcesDrawStatusBarBackground (mTopDockedOpaqueWindowState)

You can see that the SystemBars is updated accordingly through updateSystemBarsLw in PhoneWindowManager. Another interesting question in this place is that when you actually use these two Flag, you will find that App automatically extends below StatusBar and NavigationBar. Why?

Guess that it should be the App area that handles the windowsets value issued by the system. Looking at the ActionBarOverlayLayout onApplyWindowInsets method, you can find that the insets value used in the measure of ActionBarOverlayLayout is processed through computeFitSystemWindows, and check the computeFitSystemWindows method of View.

Protected boolean computeFitSystemWindows (Rect inoutInsets, Rect outLocalInsets) {

If ((mViewFlags & OPTIONAL_FITS_SYSTEM_WINDOWS) = = 0 | | mAttachInfo = = null | | (mAttachInfo.mSystemUiVisibility & SYSTEM_UI_LAYOUT_FLAGS) = = 0 & &! mAttachInfo.mOverscanRequested) {

OutLocalInsets.set (inoutInsets)

InoutInsets.set (0,0,0,0)

Return true

} else {

/ / The application wants to take care of fitting system window for

/ / the content... However we still need to take care of any overscan here.

Final Rect overscan = mAttachInfo.mOverscanInsets

OutLocalInsets.set (overscan)

InoutInsets.left-= overscan.left

InoutInsets.top-= overscan.top

InoutInsets.right-= overscan.right

InoutInsets.bottom-= overscan.bottom

Return false

}

}

You can find this place, and according to flag's judgment, the insets value of ActionBarOverlayLayout has been modified through overscan Rect (this processing has recently been ported to API 19, heh). Of course, Google does not have the courage to deal with this, so App can use the fitsSystemWindows attribute to avoid this processing, through which you can default the insets value to the padding value of the current View. Of course, App can also inherit View's fitSystemWindows method to handle insets.

SystemBar setColor support

Android added setNavigationBarColor and setStatusBarColor to Window in API 21 to further enhance the SystemBar user experience.

PhoneWindow inherits Window to implement setNavigationBarColor and setStatusBarColor. The specific code is as follows:

Public void setStatusBarColor (int color) {

MStatusBarColor = color

MForcedStatusBarColor = true

If (mDecor! = null) {

MDecor.updateColorViews (null, false / * animate * /)

}

}

Public void setNavigationBarColor (int color) {

MNavigationBarColor = color

MForcedNavigationBarColor = true

If (mDecor! = null) {

MDecor.updateColorViews (null, false / * animate * /)

MDecor.updateNavigationGuardColor ()

}

}

It is not difficult to find that the updateColorViews of DecorView is in work. By looking at the code, you can see that it is DecorView that add the corresponding ColorStateView in SystemBar, which is somewhat similar to the WindowState in PhoneWindowManager, and then operate on the view in ColotStateView, such as setBackground to change its color.

These are all the contents of the article "how to use Android SystemBar". Thank you for reading! I believe you will gain a lot after reading this article. The editor will update different knowledge for you every day. If you want to learn more knowledge, please pay attention to the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.