Fixed
Status Update
No update yet.
Comments
ch...@google.com
ch...@google.com
[Deleted User] <[Deleted User]>
I'm going to leave this here as well, for reference: http://stackoverflow.com/questions/40171801/bottomnavigationview-hides-when-scrolling-up-instead-of-down
In my use case, the BottomNavigationView is inside a fragment, inside a FrameLayout which is contained in a CoordinatorLayout and the scroll to hide technique works, but in reverse compared to how it's supposed to work. Using the BottomNavigationView directly inside the CoordinatorLayout doesn't have any scroll behavior though.
In my use case, the BottomNavigationView is inside a fragment, inside a FrameLayout which is contained in a CoordinatorLayout and the scroll to hide technique works, but in reverse compared to how it's supposed to work. Using the BottomNavigationView directly inside the CoordinatorLayout doesn't have any scroll behavior though.
ch...@google.com
I'm having the same issue. There is an estimation when this issue will be fixed?
[Deleted User] <[Deleted User]>
This has been released in support library 25.0.1.
si...@shadowfax.in
Scroll behavior is still missing. For those that are looking for one, sample project archive contains it.
va...@gmail.com
Comment has been deleted.
va...@gmail.com
Elevation is broken if you use app:itemBackground rather than android:background since it's setting the elevation on itself rather than mMenuView. Why is itemBackground exposed? Should I not just use android:background?
Description
Version used: 23.1.1, 23.3.0, 23.2.1, 23.3.0
Theme used: Custom theme based on Theme.AppCompat.Light.NoActionBar
Devices/Android versions reproduced on: Wide variety of devices and Android versions, ranging from 4.2.2 to 6.0.1
I recently started seeing the following two crashes, both of which point to problems obtaining the content view:
Relevant Portion of Stack for Crash #1:
Caused by java.lang.NullPointerException: Attempt to invoke virtual method 'int android.view.ViewGroup.getChildCount()' on a null object reference
at android.support.v7.app.AppCompatDelegateImplV7.createSubDecor(AppCompatDelegateImplV7.java:475)
at android.support.v7.app.AppCompatDelegateImplV7.ensureSubDecor(AppCompatDelegateImplV7.java:309)
at android.support.v7.app.AppCompatDelegateImplV7.setContentView(AppCompatDelegateImplV7.java:273)
at android.support.v7.app.AppCompatActivity.setContentView(AppCompatActivity.java:139)
at com.bleacherreport.android.teamstream.activities.HomeActivity.onCreate(HomeActivity.java:181)
Relevant Portion of Stack for Crash #2:
Caused by: java.lang.RuntimeException: Window couldn't find content container view
at com.android.internal.policy.impl.PhoneWindow.generateLayout(PhoneWindow.java:3611)
at com.android.internal.policy.impl.PhoneWindow.installDecor(PhoneWindow.java:3677)
at com.android.internal.policy.impl.PhoneWindow.getDecorView(PhoneWindow.java:1943)
at android.view.Window.findViewById(Window.java:990)
at android.support.v7.app.AppCompatDelegateImplV7.createSubDecor(AppCompatDelegateImplV7.java:460)
at android.support.v7.app.AppCompatDelegateImplV7.ensureSubDecor(AppCompatDelegateImplV7.java:300)
at android.support.v7.app.AppCompatDelegateImplV7.setContentView(AppCompatDelegateImplV7.java:264)
at android.support.v7.app.AppCompatActivity.setContentView(AppCompatActivity.java:129)
at com.bleacherreport.android.teamstream.activities.HomeActivity.onCreate(HomeActivity.java:186)
As you can see, the crash occurs within the onCreate() method of our HomeActivity, which extends android.support.v7.app.AppCompatActivity. Within AppCompatDelegateImplV7.createSubDecor, the call to mWindow.findViewById(android.R.id.content) sometimes returns null (crash #1). This in turn results in a NullPointerException on line 475. In other situations, even on the same version of Android, we see crash #2, with the error message, "Window couldn't find content container view". To me, this suggests a race condition within the appcompat code.
We were able to reduce the frequency of crashes by downgrading Play Services from 8.4 to 7.8. (We use Play Services exclusively for ads.) I can see no connection between Play Services and this crash, except that one version may have a longer startup than the other, which could alter the timing such that a race condition is more likely to occur.
In our experience, the frequency of crashes is also higher on emulator than on device. Similarly, we are unable to reproduce the crash in a debug build, but can recreate it with some frequency in a release build. These seemingly unrelated factors all seem to support the theory that there's a race condition here.
Based on analytical logging, the savedInstanceState parameter passed into onCreate() is always non-null when the crash occurs, suggesting that the problem is specifically related to recreating the HomeActivity. We use android:configChanges="orientation|screenSize|keyboardHidden" in our AndroidManifest.xml file, so I don't think the Activity is being recreated due to rotation. Instead, it seems that the Activity instance is dropped and then recreated as part of memory management. This is consistent with the fact that we can only reproduce the crash with any frequency by setting the "Don't keep activities" developer option.
Any suggestions? Anything we can do to help identify the source of the problem?