What happened to windowContentOverlay in Android API 18?

Question

After upgrading my phone to Android 4.3 I noticed the shadow below the actionbar is not showing anymore. In my app I've got a custom shadow using windowContentOverlay:

<item name="android:windowContentOverlay">@drawable/shadows_bottom</item>

It's always been showing but now it's gone on API 18. Removing that line from the theme doesn't change anything. while on other API versions it shows a default slight shadow.

Anyone else has noticed that issue?

Comedown

I just noticed the same thing in our app today. Hoping there's a simple solution. – Stoichiometry

Are you using ActionBarSherlock? – Gulf

Looks like there's some more details on this change from the ActionBarSherlock guys: github.com/JakeWharton/ActionBarSherlock/issues/1003 – Stoichiometry

If you look carefully, the shadow is now missing from several first-party apps. In fact, dumping the view hierarchy in DDMS shows that the ImageView showing the windowContentOverlay drawable is not present in the new ActionBar layout at all. – Gulf

Interesting. Yeah I'm using ABS but it shouldn't make any difference for 4.3. I noticed only Spotify has its shadow showing. I'm wondering how they do that. Maybe a nine patch on the action bar background? – Comedown

my temporary solution as already posted on the github link was to use a nine path drawable as the background of the actionbar and set the windowContentOverlay to @null. The problem is that you cannot achieve a perfect solution, because in the latest APIs the shadow was positioned under the actionbar, so if your shadow starts now above with lets say grey and at the end it finishes with white, that means that the last pixels of the action bar will be white. If you now select an actionbar item you will see that the "selected color" doesn't align with the action bar visually – Thoron

yeah I tried that solution it was not perfect as you described. Right now I'm doing what I think Spotify does. I'm having my windowContentOverlay sticked on top of the layout root view. It gives the same result. It feels like a hack, I'm wondering why they changed that without writing anything around. – Comedown

This appears to have been fixed as of API level 19. – Stoichiometry

Answer 1

This is officially a bug and will be fixed for next platform release: https://code.google.com/p/android/issues/detail?id=58280

UPDATE: This seems to be fixed on API level 19

Comedown

I got the build target API 19 and still getting no resource found :/ – Molybdenite

I think the device has to have API 19(4.4). This issue happens on 4.3, but not on 4.2 or 4.1.2! – Hobby

Answer 2

I was able to work around this platform bug by adding the following method to my base FragmentActivity and calling it in onCreate after the layout has been inflated:

/**
 * Set the window content overlay on device's that don't respect the theme
 * attribute.
 */
private void setWindowContentOverlayCompat() {
    if (Build.VERSION.SDK_INT == Build.VERSION_CODES.JELLY_BEAN_MR2) {
        // Get the content view
        View contentView = findViewById(android.R.id.content);

        // Make sure it's a valid instance of a FrameLayout
        if (contentView instanceof FrameLayout) {
            TypedValue tv = new TypedValue();

            // Get the windowContentOverlay value of the current theme
            if (getTheme().resolveAttribute(
                    android.R.attr.windowContentOverlay, tv, true)) {

                // If it's a valid resource, set it as the foreground drawable
                // for the content view
                if (tv.resourceId != 0) {
                    ((FrameLayout) contentView).setForeground(
                            getResources().getDrawable(tv.resourceId));
                }
            }
        }
    }
}

This works nicely because you don't have to change your themes or dynamically add views to your layouts. It should be forward compatible and can be easily removed once this bug has been fixed.

Stoichiometry

If/when Google fixes the bug, will apps using this fix end up with double windowContentOverlays until they get updated? – Gironde

@DaveFeldman it depends. If they increment the API version then no, apps won't have a double overlay. If they release an incremental update that doesn't change the SDK version than yes, you might have users with a duplicate overlay. – Stoichiometry

Thanks, this works for me! I suggest to declare the method setWindowContentOverlayCompat as protected in your base activity, then extend this base activity and call the method after setContentView in onCreate. – Bluebonnet