NTP, change the card elevation from setElevation to a 9 patch file

NTP, change the card elevation from setElevation to a 9 patch file

Because it's a nine-patch, this ensures the shadow will be visible when drawing into a bitmap (which disables hardware rendering). It also allows drawing the shadow pre-L.

Videos: https://drive.google.com/corp/drive/u/0/folders/0B1IgAIJ9cgizRW9CRHdPd0FLUVE

BUG=616706
Committed: https://crrev.com/96561c6f52c31ae54f2519212d459bccb79ecb50
Cr-Commit-Position: refs/heads/master@{#402871}

[mcwilliams, 2016-06-27 13:24:25]

Description was changed from

==========
Zine card elevetion from setElevation to 9 patch files

Because it's a nine-patch, this ensures the shadow will be visible when drawing
into a bitmap (which disables hardware rendering). It also allows drawing the
shadow pre-L.

Still need to remove the margin left and right by 2px to avoid the rounded
corners but will do this in a follow up cl.

BUG=616706
==========

to

==========
Zine card elevetion from setElevation to 9 patch files

Because it's a nine-patch, this ensures the shadow will be visible when drawing
into a bitmap (which disables hardware rendering). It also allows drawing the
shadow pre-L.

BUG=616706
==========

[mcwilliams, 2016-06-27 13:29:20]

mcwilliams@chromium.org changed reviewers:
+ bauerb@chromium.org

[mcwilliams, 2016-06-27 13:33:35]

Description was changed from

==========
Zine card elevetion from setElevation to 9 patch files

Because it's a nine-patch, this ensures the shadow will be visible when drawing
into a bitmap (which disables hardware rendering). It also allows drawing the
shadow pre-L.

BUG=616706
==========

to

==========
Zine card elevetion from setElevation to 9 patch files

Because it's a nine-patch, this ensures the shadow will be visible when drawing
into a bitmap (which disables hardware rendering). It also allows drawing the
shadow pre-L.

Videos:
https://drive.google.com/corp/drive/u/0/folders/0B1IgAIJ9cgizRW9CRHdPd0FLUVE

BUG=616706
==========

[mcwilliams, 2016-06-27 13:40:14]

The CQ bit was checked by mcwilliams@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-27 13:40:30]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-06-27 14:14:19]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-27 14:14:20]

Dry run: This issue passed the CQ dry run.

[Bernhard Bauer, 2016-06-27 16:47:45]

CL description nits:
* Remove code names
* Use imperative style (see http://chris.beams.io/posts/git-commit/#imperative)
* s/elevetion/elevation/

Thanks! 😃

https://codereview.chromium.org/2088793004/diff/40001/chrome/android/java/src...
File
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardItemDecoration.java
(right):

https://codereview.chromium.org/2088793004/diff/40001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardItemDecoration.java:16:
* A decorator that adds elevation effect to recyclerView cards.
Nit: Capitalize RecyclerView.

https://codereview.chromium.org/2088793004/diff/40001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardItemDecoration.java:31:
Rect outRect, View view, RecyclerView recyclerView, RecyclerView.State state) {
I'm not sure ItemDecoration is the right place for this anymore -- this method
is supposed to update |outRect|, but doesn't touch it at all now, and instead
just updates the LayoutParams.

I wonder whether we should just override onLayout() in the
NewTabPageRecyclerView and dispatch to a method in the ViewHolders for all of
its children. Then the CardViewHolder could update its LayoutParams there, which
would also keep the logic that compensates for the 9-patch border in a single
place.

https://codereview.chromium.org/2088793004/diff/40001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardItemDecoration.java:32:
Adapter<?> adapter = recyclerView.getAdapter();
Move this to where it's used?

https://codereview.chromium.org/2088793004/diff/40001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardItemDecoration.java:45:
// due to tab switching and rendering of server shadows. Each card has the full
elevation
Server shadows? Also, I know what why tab switching is mentioned here, but for a
casual reader the connection is not going to be clear. Maybe just add a link to
crbug.com by way of explanation?

https://codereview.chromium.org/2088793004/diff/40001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardItemDecoration.java:58:
params.leftMargin = -mCards9PatchAdjustment;
Could we set this in the constructor for CardViewHolder? This doesn't seem like
it would change dynamically.

[mcwilliams, 2016-06-29 10:12:37]

PTAL

https://codereview.chromium.org/2088793004/diff/40001/chrome/android/java/src...
File
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardItemDecoration.java
(right):

https://codereview.chromium.org/2088793004/diff/40001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardItemDecoration.java:16:
* A decorator that adds elevation effect to recyclerView cards.
On 2016/06/27 16:47:44, Bernhard Bauer wrote:
> Nit: Capitalize RecyclerView.

Done.

https://codereview.chromium.org/2088793004/diff/40001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardItemDecoration.java:31:
Rect outRect, View view, RecyclerView recyclerView, RecyclerView.State state) {
On 2016/06/27 16:47:44, Bernhard Bauer wrote:
> I'm not sure ItemDecoration is the right place for this anymore -- this method
> is supposed to update |outRect|, but doesn't touch it at all now, and instead
> just updates the LayoutParams.
> 
> I wonder whether we should just override onLayout() in the
> NewTabPageRecyclerView and dispatch to a method in the ViewHolders for all of
> its children. Then the CardViewHolder could update its LayoutParams there,
which
> would also keep the logic that compensates for the 9-patch border in a single
> place.

Done.

https://codereview.chromium.org/2088793004/diff/40001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardItemDecoration.java:32:
Adapter<?> adapter = recyclerView.getAdapter();
On 2016/06/27 16:47:44, Bernhard Bauer wrote:
> Move this to where it's used?

Done.

https://codereview.chromium.org/2088793004/diff/40001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardItemDecoration.java:45:
// due to tab switching and rendering of server shadows. Each card has the full
elevation
On 2016/06/27 16:47:44, Bernhard Bauer wrote:
> Server shadows? Also, I know what why tab switching is mentioned here, but for
a
> casual reader the connection is not going to be clear. Maybe just add a link
to
> http://crbug.com by way of explanation?

Done.

https://codereview.chromium.org/2088793004/diff/40001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardItemDecoration.java:58:
params.leftMargin = -mCards9PatchAdjustment;
On 2016/06/27 16:47:45, Bernhard Bauer wrote:
> Could we set this in the constructor for CardViewHolder? This doesn't seem
like
> it would change dynamically.

Moved

[mcwilliams, 2016-06-29 10:21:50]

Description was changed from

==========
Zine card elevetion from setElevation to 9 patch files

Because it's a nine-patch, this ensures the shadow will be visible when drawing
into a bitmap (which disables hardware rendering). It also allows drawing the
shadow pre-L.

Videos:
https://drive.google.com/corp/drive/u/0/folders/0B1IgAIJ9cgizRW9CRHdPd0FLUVE

BUG=616706
==========

to

==========
NTP, change the card elevation from setElevation to a 9 patch file

Because it's a nine-patch, this ensures the shadow will be visible when drawing
into a bitmap (which disables hardware rendering). It also allows drawing the
shadow pre-L.

Videos:
https://drive.google.com/corp/drive/u/0/folders/0B1IgAIJ9cgizRW9CRHdPd0FLUVE

BUG=616706
==========

[Bernhard Bauer, 2016-06-29 11:22:28]

https://codereview.chromium.org/2088793004/diff/60001/chrome/android/java/res...
File chrome/android/java/res/values/dimens.xml (right):

https://codereview.chromium.org/2088793004/diff/60001/chrome/android/java/res...
chrome/android/java/res/values/dimens.xml:290: <dimen
name="snippets_card_adjust_9_patch">2dp</dimen>
Nit: Could we call this |snippets_card_9_patch_adjustment| so it's consistent
with the variable?

https://codereview.chromium.org/2088793004/diff/60001/chrome/android/java/src...
File
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardViewHolder.java
(right):

https://codereview.chromium.org/2088793004/diff/60001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardViewHolder.java:99:
int childPos = mRecyclerView.getChildAdapterPosition(itemView);
You can get this directly via getAdapterPosition().

https://codereview.chromium.org/2088793004/diff/60001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardViewHolder.java:102:
// due to tab switching and rendering of server shadows. Each card has the full
elevation
https://codereview.chromium.org/2088793004/diff/40001/chrome/android/java/src...
still applies :)

https://codereview.chromium.org/2088793004/diff/60001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardViewHolder.java:116:
if (!isPeeking()) {
Wait, doesn't this evaluate to `getParams().leftMargin ==
-mCards9PatchAdjustment`, which would make this a no-op?

https://codereview.chromium.org/2088793004/diff/60001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardViewHolder.java:138:
return getParams().leftMargin != -mCards9PatchAdjustment;
OK, finding out the peeking state from the layout parameters is very awkward. I
would propose we change |mPeekPadding| to a value between 0 and 1 that indicates
to what extent the card is peeking, and we derive everything else from that.
That should also fix the bug below :)

https://codereview.chromium.org/2088793004/diff/60001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardViewHolder.java:158:
// can have full bleed.
I think I would move this comment to Javadoc for |mCards9PatchAdjustment|
instead of duplicating it.

https://codereview.chromium.org/2088793004/diff/60001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardViewHolder.java:173:
snippetChild.setAlpha(mPeekPadding / (float) mMaxPeekPadding);
Hm, |mPeekPadding| also contains the adjustment, which doesn't seem quite right
for calculating the alpha value of the card here.

https://codereview.chromium.org/2088793004/diff/60001/chrome/android/java/src...
File
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/NewTabPageRecyclerView.java
(right):

https://codereview.chromium.org/2088793004/diff/60001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/NewTabPageRecyclerView.java:111:
protected void onLayout(boolean changed, int l, int t, int r, int b) {
Write out the parameter names?

https://codereview.chromium.org/2088793004/diff/60001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/NewTabPageRecyclerView.java:116:
if (viewHolder == null) return;
Does this really happen?

[mcwilliams, 2016-06-29 14:15:55]

PTAL

https://codereview.chromium.org/2088793004/diff/60001/chrome/android/java/res...
File chrome/android/java/res/values/dimens.xml (right):

https://codereview.chromium.org/2088793004/diff/60001/chrome/android/java/res...
chrome/android/java/res/values/dimens.xml:290: <dimen
name="snippets_card_adjust_9_patch">2dp</dimen>
On 2016/06/29 11:22:27, Bernhard Bauer wrote:
> Nit: Could we call this |snippets_card_9_patch_adjustment| so it's consistent
> with the variable?

Done.

https://codereview.chromium.org/2088793004/diff/60001/chrome/android/java/src...
File
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardViewHolder.java
(right):

https://codereview.chromium.org/2088793004/diff/60001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardViewHolder.java:99:
int childPos = mRecyclerView.getChildAdapterPosition(itemView);
On 2016/06/29 11:22:27, Bernhard Bauer wrote:
> You can get this directly via getAdapterPosition().

Done.

https://codereview.chromium.org/2088793004/diff/60001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardViewHolder.java:102:
// due to tab switching and rendering of server shadows. Each card has the full
elevation
On 2016/06/29 11:22:27, Bernhard Bauer wrote:
>
https://codereview.chromium.org/2088793004/diff/40001/chrome/android/java/src...
> still applies :)

This was missing a commit - updated

https://codereview.chromium.org/2088793004/diff/60001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardViewHolder.java:116:
if (!isPeeking()) {
On 2016/06/29 11:22:27, Bernhard Bauer wrote:
> Wait, doesn't this evaluate to `getParams().leftMargin ==
> -mCards9PatchAdjustment`, which would make this a no-op?

Done.

https://codereview.chromium.org/2088793004/diff/60001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardViewHolder.java:138:
return getParams().leftMargin != -mCards9PatchAdjustment;
On 2016/06/29 11:22:27, Bernhard Bauer wrote:
> OK, finding out the peeking state from the layout parameters is very awkward.
I
> would propose we change |mPeekPadding| to a value between 0 and 1 that
indicates
> to what extent the card is peeking, and we derive everything else from that.
> That should also fix the bug below :)

Added a TODO as discussed

https://codereview.chromium.org/2088793004/diff/60001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardViewHolder.java:158:
// can have full bleed.
On 2016/06/29 11:22:27, Bernhard Bauer wrote:
> I think I would move this comment to Javadoc for |mCards9PatchAdjustment|
> instead of duplicating it.

Done.

https://codereview.chromium.org/2088793004/diff/60001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardViewHolder.java:173:
snippetChild.setAlpha(mPeekPadding / (float) mMaxPeekPadding);
On 2016/06/29 11:22:27, Bernhard Bauer wrote:
> Hm, |mPeekPadding| also contains the adjustment, which doesn't seem quite
right
> for calculating the alpha value of the card here.

Done.

https://codereview.chromium.org/2088793004/diff/60001/chrome/android/java/src...
File
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/NewTabPageRecyclerView.java
(right):

https://codereview.chromium.org/2088793004/diff/60001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/NewTabPageRecyclerView.java:111:
protected void onLayout(boolean changed, int l, int t, int r, int b) {
On 2016/06/29 11:22:28, Bernhard Bauer wrote:
> Write out the parameter names?

Copied directly from onLayout from RecyclerView - we are not using these in this
function so happy to leave as is

https://codereview.chromium.org/2088793004/diff/60001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/NewTabPageRecyclerView.java:116:
if (viewHolder == null) return;
On 2016/06/29 11:22:28, Bernhard Bauer wrote:
> Does this really happen?

Yes unfortunately

[Bernhard Bauer, 2016-06-29 15:42:26]

https://codereview.chromium.org/2088793004/diff/100001/chrome/android/java/sr...
File
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardViewHolder.java
(right):

https://codereview.chromium.org/2088793004/diff/100001/chrome/android/java/sr...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardViewHolder.java:48:
// Due to the card background being a 9 patch file - the card border shadow will
be part of
Nit: Make this a Javadoc comment?

https://codereview.chromium.org/2088793004/diff/100001/chrome/android/java/sr...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardViewHolder.java:53:
private final NewTabPageRecyclerView mRecyclerView;
Move these up so that final members are together?

https://codereview.chromium.org/2088793004/diff/100001/chrome/android/java/sr...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardViewHolder.java:130:
return getParams().leftMargin != -mCards9PatchAdjustment;
Now that we are not changing mPeekPadding anymore, we could keep this logic the
same, so this method doesn't need to know how the margin is calculated.

https://codereview.chromium.org/2088793004/diff/100001/chrome/android/java/sr...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardViewHolder.java:153:
itemView.setPadding(mPeekPadding, mMaxPeekPadding, mPeekPadding,
mMaxPeekPadding);
Now you are not including the 9-patch adjustment in the padding value here
anymore. Is that intentional?

[mcwilliams, 2016-06-29 16:00:58]

https://codereview.chromium.org/2088793004/diff/100001/chrome/android/java/sr...
File
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardViewHolder.java
(right):

https://codereview.chromium.org/2088793004/diff/100001/chrome/android/java/sr...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardViewHolder.java:48:
// Due to the card background being a 9 patch file - the card border shadow will
be part of
On 2016/06/29 15:42:26, Bernhard Bauer wrote:
> Nit: Make this a Javadoc comment?

Done.

https://codereview.chromium.org/2088793004/diff/100001/chrome/android/java/sr...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardViewHolder.java:53:
private final NewTabPageRecyclerView mRecyclerView;
On 2016/06/29 15:42:26, Bernhard Bauer wrote:
> Move these up so that final members are together?

Done.

https://codereview.chromium.org/2088793004/diff/100001/chrome/android/java/sr...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardViewHolder.java:130:
return getParams().leftMargin != -mCards9PatchAdjustment;
On 2016/06/29 15:42:26, Bernhard Bauer wrote:
> Now that we are not changing mPeekPadding anymore, we could keep this logic
the
> same, so this method doesn't need to know how the margin is calculated.

I still prefer to actually check with values whether the card is peeking than
previously set numbers but will look at this again when I look at the follow up

https://codereview.chromium.org/2088793004/diff/100001/chrome/android/java/sr...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardViewHolder.java:153:
itemView.setPadding(mPeekPadding, mMaxPeekPadding, mPeekPadding,
mMaxPeekPadding);
On 2016/06/29 15:42:26, Bernhard Bauer wrote:
> Now you are not including the 9-patch adjustment in the padding value here
> anymore. Is that intentional?

Yes that is fine as we are adjusting the margin below

[Bernhard Bauer, 2016-06-29 16:08:54]

lgtm

https://codereview.chromium.org/2088793004/diff/100001/chrome/android/java/sr...
File
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardViewHolder.java
(right):

https://codereview.chromium.org/2088793004/diff/100001/chrome/android/java/sr...
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardViewHolder.java:153:
itemView.setPadding(mPeekPadding, mMaxPeekPadding, mPeekPadding,
mMaxPeekPadding);
On 2016/06/29 16:00:58, mcwilliams wrote:
> On 2016/06/29 15:42:26, Bernhard Bauer wrote:
> > Now you are not including the 9-patch adjustment in the padding value here
> > anymore. Is that intentional?
> 
> Yes that is fine as we are adjusting the margin below

OK, I'm going to assume you would be aware of the padding being off by 2dp :)

[mcwilliams, 2016-06-29 16:10:52]

On 2016/06/29 16:08:54, Bernhard Bauer wrote:
> lgtm
> 
>
https://codereview.chromium.org/2088793004/diff/100001/chrome/android/java/sr...
> File
>
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardViewHolder.java
> (right):
> 
>
https://codereview.chromium.org/2088793004/diff/100001/chrome/android/java/sr...
>
chrome/android/java/src/org/chromium/chrome/browser/ntp/cards/CardViewHolder.java:153:
> itemView.setPadding(mPeekPadding, mMaxPeekPadding, mPeekPadding,
> mMaxPeekPadding);
> On 2016/06/29 16:00:58, mcwilliams wrote:
> > On 2016/06/29 15:42:26, Bernhard Bauer wrote:
> > > Now you are not including the 9-patch adjustment in the padding value here
> > > anymore. Is that intentional?
> > 
> > Yes that is fine as we are adjusting the margin below
> 
> OK, I'm going to assume you would be aware of the padding being off by 2dp :)

Because the margin handles the offset - the padding is accurate :/

[mcwilliams, 2016-06-29 16:11:55]

The CQ bit was checked by mcwilliams@chromium.org

[commit-bot: I haz the power, 2016-06-29 16:12:26]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-06-29 17:26:01]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-29 17:26:02]

Try jobs failed on following builders:
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[mcwilliams, 2016-06-29 17:35:56]

The CQ bit was checked by mcwilliams@chromium.org

[commit-bot: I haz the power, 2016-06-29 17:37:23]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-06-29 18:17:59]

Description was changed from

==========
NTP, change the card elevation from setElevation to a 9 patch file

Because it's a nine-patch, this ensures the shadow will be visible when drawing
into a bitmap (which disables hardware rendering). It also allows drawing the
shadow pre-L.

Videos:
https://drive.google.com/corp/drive/u/0/folders/0B1IgAIJ9cgizRW9CRHdPd0FLUVE

BUG=616706
==========

to

==========
NTP, change the card elevation from setElevation to a 9 patch file

Because it's a nine-patch, this ensures the shadow will be visible when drawing
into a bitmap (which disables hardware rendering). It also allows drawing the
shadow pre-L.

Videos:
https://drive.google.com/corp/drive/u/0/folders/0B1IgAIJ9cgizRW9CRHdPd0FLUVE

BUG=616706
==========

[commit-bot: I haz the power, 2016-06-29 18:18:01]

Committed patchset #7 (id:120001)

[commit-bot: I haz the power, 2016-06-29 18:18:04]

CQ bit was unchecked.

[commit-bot: I haz the power, 2016-06-29 18:19:57]

Description was changed from

==========
NTP, change the card elevation from setElevation to a 9 patch file

Because it's a nine-patch, this ensures the shadow will be visible when drawing
into a bitmap (which disables hardware rendering). It also allows drawing the
shadow pre-L.

Videos:
https://drive.google.com/corp/drive/u/0/folders/0B1IgAIJ9cgizRW9CRHdPd0FLUVE

BUG=616706
==========

to

==========
NTP, change the card elevation from setElevation to a 9 patch file

Because it's a nine-patch, this ensures the shadow will be visible when drawing
into a bitmap (which disables hardware rendering). It also allows drawing the
shadow pre-L.

Videos:
https://drive.google.com/corp/drive/u/0/folders/0B1IgAIJ9cgizRW9CRHdPd0FLUVE

BUG=616706

Committed: https://crrev.com/96561c6f52c31ae54f2519212d459bccb79ecb50
Cr-Commit-Position: refs/heads/master@{#402871}
==========

[commit-bot: I haz the power, 2016-06-29 18:19:59]

Patchset 7 (id:??) landed as
https://crrev.com/96561c6f52c31ae54f2519212d459bccb79ecb50
Cr-Commit-Position: refs/heads/master@{#402871}