29

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?

Renjith
  • 5,745
  • 9
  • 28
  • 42
Romain Piel
  • 10,535
  • 15
  • 67
  • 105
  • I just noticed the same thing in our app today. Hoping there's a simple solution. – twaddington Jul 30 '13 at 22:31
  • Are you using ActionBarSherlock? – tad Jul 30 '13 at 22:34
  • Looks like there's some more details on this change from the ActionBarSherlock guys: https://github.com/JakeWharton/ActionBarSherlock/issues/1003 – twaddington Jul 30 '13 at 22:35
  • 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. – tad Jul 31 '13 at 00:01
  • 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? – Romain Piel Jul 31 '13 at 06:28
  • 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 – David Aug 06 '13 at 11:21
  • 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. – Romain Piel Aug 06 '13 at 12:06
  • 1
    This appears to have been fixed as of API level 19. – twaddington Nov 08 '13 at 19:30
  • thanks for the update, answer updated – Romain Piel Nov 09 '13 at 08:18

2 Answers2

30

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.

twaddington
  • 11,471
  • 5
  • 31
  • 43
  • If/when Google fixes the bug, will apps using this fix end up with double windowContentOverlays until they get updated? – Dave Feldman Oct 11 '13 at 20:03
  • @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. – twaddington Oct 12 '13 at 00:40
  • 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. – moondroid Feb 07 '14 at 10:42
18

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

Romain Piel
  • 10,535
  • 15
  • 67
  • 105