Program: 199878
Project: 199878
Buggy source:
/** 
 * Called by the view hierarchy when the content insets for a window have changed, to allow it to adjust its content to fit within those windows. The content insets tell you the space that the status bar, input method, and other system windows infringe on the application's window. <p>You do not normally need to deal with this function, since the default window decoration given to applications takes care of applying it to the content of the window.  If you use   {@link #SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN}or   {@link #SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION} this will not be the case,and your content can be placed under those system elements.  You can then use this method within your view hierarchy if you have parts of your UI which you would like to ensure are not being covered. <p>The default implementation of this method simply applies the content insets to the view's padding, consuming that content (modifying the insets to be 0), and returning true.  This behavior is off by default, but can be enabled through  {@link #setFitsSystemWindows(boolean)}. <p>This function's traversal down the hierarchy is depth-first.  The same content insets object is propagated down the hierarchy, so any changes made to it will be seen by all following views (including potentially ones above in the hierarchy since this is a depth-first traversal).  The first view that returns true will abort the entire traversal. <p>The default implementation works well for a situation where it is used with a container that covers the entire window, allowing it to apply the appropriate insets to its content on all edges.  If you need a more complicated layout (such as two different views fitting system windows, one on the top of the window, and one on the bottom), you can override the method and handle the insets however you would like. Note that the insets provided by the framework are always relative to the far edges of the window, not accounting for the location of the called view within that window.  (In fact when this method is called you do not yet know where the layout will place the view, as it is done before layout happens.) <p>Note: unlike many View methods, there is no dispatch phase to this call.  If you are overriding it in a ViewGroup and want to allow the call to continue to your children, you must be sure to call the super implementation. <p>Here is a sample layout that makes use of fitting system windows to have controls for a video view placed inside of the window decorations that it hides and shows.  This can be used with code like the second sample (video player) shown in   {@link #setSystemUiVisibility(int)}.  {@sample development/samples/ApiDemos/res/layout/video_player.xml complete}
 * @param insets Current content insets of the window.  Prior to{@link android.os.Build.VERSION_CODES#JELLY_BEAN} you must not modifythe insets or else you and Android will be unhappy.
 * @return {@code true} if this view applied the insets and it should notcontinue propagating further down the hierarchy,  {@code false} otherwise.
 * @see #getFitsSystemWindows()
 * @see #setFitsSystemWindows(boolean)
 * @see #setSystemUiVisibility(int)
 * @deprecated As of API XX use {@link #dispatchApplyWindowInsets(WindowInsets)} to applyinsets to views. Views should override  {@link #onApplyWindowInsets(WindowInsets)} or use{@link #setOnApplyWindowInsetsListener(android.view.View.OnApplyWindowInsetsListener)}to implement handling their own insets.
 */
protected boolean fitSystemWindows(Rect insets){
  if ((mPrivateFlags3 & PFLAG3_APPLYING_INSETS) == 0) {
    try {
      mPrivateFlags3|=PFLAG3_FITTING_SYSTEM_WINDOWS;
      return !dispatchApplyWindowInsets(new WindowInsets(insets)).hasInsets();
    }
  finally {
      mPrivateFlags3&=PFLAG3_FITTING_SYSTEM_WINDOWS;
    }
  }
 else {
    return fitSystemWindowsInt(insets);
  }
}

Fixed version (ground truth):
/** 
 * Called by the view hierarchy when the content insets for a window have changed, to allow it to adjust its content to fit within those windows. The content insets tell you the space that the status bar, input method, and other system windows infringe on the application's window. <p>You do not normally need to deal with this function, since the default window decoration given to applications takes care of applying it to the content of the window.  If you use   {@link #SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN}or   {@link #SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION} this will not be the case,and your content can be placed under those system elements.  You can then use this method within your view hierarchy if you have parts of your UI which you would like to ensure are not being covered. <p>The default implementation of this method simply applies the content insets to the view's padding, consuming that content (modifying the insets to be 0), and returning true.  This behavior is off by default, but can be enabled through  {@link #setFitsSystemWindows(boolean)}. <p>This function's traversal down the hierarchy is depth-first.  The same content insets object is propagated down the hierarchy, so any changes made to it will be seen by all following views (including potentially ones above in the hierarchy since this is a depth-first traversal).  The first view that returns true will abort the entire traversal. <p>The default implementation works well for a situation where it is used with a container that covers the entire window, allowing it to apply the appropriate insets to its content on all edges.  If you need a more complicated layout (such as two different views fitting system windows, one on the top of the window, and one on the bottom), you can override the method and handle the insets however you would like. Note that the insets provided by the framework are always relative to the far edges of the window, not accounting for the location of the called view within that window.  (In fact when this method is called you do not yet know where the layout will place the view, as it is done before layout happens.) <p>Note: unlike many View methods, there is no dispatch phase to this call.  If you are overriding it in a ViewGroup and want to allow the call to continue to your children, you must be sure to call the super implementation. <p>Here is a sample layout that makes use of fitting system windows to have controls for a video view placed inside of the window decorations that it hides and shows.  This can be used with code like the second sample (video player) shown in   {@link #setSystemUiVisibility(int)}.  {@sample development/samples/ApiDemos/res/layout/video_player.xml complete}
 * @param insets Current content insets of the window.  Prior to{@link android.os.Build.VERSION_CODES#JELLY_BEAN} you must not modifythe insets or else you and Android will be unhappy.
 * @return {@code true} if this view applied the insets and it should notcontinue propagating further down the hierarchy,  {@code false} otherwise.
 * @see #getFitsSystemWindows()
 * @see #setFitsSystemWindows(boolean)
 * @see #setSystemUiVisibility(int)
 * @deprecated As of API XX use {@link #dispatchApplyWindowInsets(WindowInsets)} to applyinsets to views. Views should override  {@link #onApplyWindowInsets(WindowInsets)} or use{@link #setOnApplyWindowInsetsListener(android.view.View.OnApplyWindowInsetsListener)}to implement handling their own insets.
 */
protected boolean fitSystemWindows(Rect insets){
  if ((mPrivateFlags3 & PFLAG3_APPLYING_INSETS) == 0) {
    try {
      mPrivateFlags3|=PFLAG3_FITTING_SYSTEM_WINDOWS;
      return !dispatchApplyWindowInsets(new WindowInsets(insets)).hasInsets();
    }
  finally {
      mPrivateFlags3&=~PFLAG3_FITTING_SYSTEM_WINDOWS;
    }
  }
 else {
    return fitSystemWindowsInt(insets);
  }
}