Revert of Add 200MS delay before starting toolbar scale animation

Revert of Add 200MS delay before starting toolbar scale animation (patchset #2 id:20001 of https://codereview.chromium.org/1389293003/ )

Reason for revert:
Breaks the Android Builder

[17814/24986] ACTION Packaging ui_android_unittests
Warning: org.chromium.test.reporter.TestStatusReporter: can't find referenced
method 'void postOnUiThreadDelayed(java.lang.Runnable,long)' in class
org.chromium.base.ThreadUtils
Warning: org.chromium.test.reporter.TestStatusReporter$1: can't find referenced
method 'void postOnUiThreadDelayed(java.lang.Runnable,long)' in class
org.chromium.base.ThreadUtils
Warning: there were 2 unresolved references to program class members.
         Your input classes appear to be inconsistent.
         You may need to recompile them and try again.
         Alternatively, you may have to specify the option
         '-dontskipnonpubliclibraryclassmembers'.
Error: Please correct the above warnings first.

https://build.chromium.org/p/chromium/builders/Android/builds/48738

Original issue's description:
> Add 200MS delay before starting toolbar scale animation
>
> Title scale-down animation might happen at a too early stage, making
> users confused about what they see. This CL adds a 200MS delay between
> toolbar initialization and the time we decide to start to animate.
>
> BUG=505620
>
> Committed: https://crrev.com/36f275146662f6067e34695a97e98bd146c47379
> Cr-Commit-Position: refs/heads/master@{#358862}

TBR=yusufo@chromium.org,yfriedman@chromium.org,ianwen@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=505620
Committed: https://crrev.com/3093155ca9a4718c7e5076fb26845a3e936385f0
Cr-Commit-Position: refs/heads/master@{#358876}

[robliao, 2015-11-10 19:38:48]

Created Revert of Add 200MS delay before starting toolbar scale animation

[Ian Wen, 2015-11-10 19:40:15]

Yeah it seems the dry run did not catch what Yaron previously was worried about.

Maybe I should update the proguard as well.

[commit-bot: I haz the power, 2015-11-10 19:41:29]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1438583003/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1438583003/1

[commit-bot: I haz the power, 2015-11-10 19:43:57]

Committed patchset #1 (id:1)

[Yaron, 2015-11-10 19:44:27]

On 2015/11/10 19:40:15, Ian Wen wrote:
> Yeah it seems the dry run did not catch what Yaron previously was worried
about.
> 
> Maybe I should update the proguard as well.

In the future if I ask you to try something, please do it. :(
It's not exactly hard to build and run the tests in release

The revert lgtm

[commit-bot: I haz the power, 2015-11-10 19:44:43]

Patchset 1 (id:??) landed as
https://crrev.com/3093155ca9a4718c7e5076fb26845a3e936385f0
Cr-Commit-Position: refs/heads/master@{#358876}

[Ian Wen, 2015-11-10 19:53:14]

On 2015/11/10 19:44:27, Yaron wrote:
> On 2015/11/10 19:40:15, Ian Wen wrote:
> > Yeah it seems the dry run did not catch what Yaron previously was worried
> about.
> > 
> > Maybe I should update the proguard as well.
> 
> In the future if I ask you to try something, please do it. :(
> It's not exactly hard to build and run the tests in release
> 
> The revert lgtm

So we do not have release testing bots in the CQ, right? I specifically ran
dry-run first before commiting, bearing the idea that some bot would catch it...

[Yaron, 2015-11-10 20:13:06]

On 2015/11/10 19:53:14, Ian Wen wrote:
> On 2015/11/10 19:44:27, Yaron wrote:
> > On 2015/11/10 19:40:15, Ian Wen wrote:
> > > Yeah it seems the dry run did not catch what Yaron previously was worried
> > about.
> > > 
> > > Maybe I should update the proguard as well.
> > 
> > In the future if I ask you to try something, please do it. :(
> > It's not exactly hard to build and run the tests in release
> > 
> > The revert lgtm
> 
> So we do not have release testing bots in the CQ, right? I specifically ran
> dry-run first before commiting, bearing the idea that some bot would catch
it...

Now I'm confused -
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_android_r...
looks to be a release bot

[robliao, 2015-11-10 20:23:31]

On 2015/11/10 20:13:06, Yaron wrote:
> On 2015/11/10 19:53:14, Ian Wen wrote:
> > On 2015/11/10 19:44:27, Yaron wrote:
> > > On 2015/11/10 19:40:15, Ian Wen wrote:
> > > > Yeah it seems the dry run did not catch what Yaron previously was
worried
> > > about.
> > > > 
> > > > Maybe I should update the proguard as well.
> > > 
> > > In the future if I ask you to try something, please do it. :(
> > > It's not exactly hard to build and run the tests in release
> > > 
> > > The revert lgtm
> > 
> > So we do not have release testing bots in the CQ, right? I specifically ran
> > dry-run first before commiting, bearing the idea that some bot would catch
> it...
> 
> Now I'm confused -
>
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_android_r...
> looks to be a release bot

I wouldn't be surprised if there were some differences between the CQ and the
linux android trybot. However, I don't see any obvious ones thus far. Then
again, I don't build Android much.

[Ian Wen, 2015-11-10 20:38:11]

ianwen@chromium.org changed reviewers:
+ newt@chromium.org

[Ian Wen, 2015-11-10 20:38:11]

Okay Newton helped me find the reason. Like Robert said, there is indeed some
minor differences between the release bot in CQ and the bot in waterfall.

Android Release bot in waterfall builds cronet_sample_apk, which is not built by
its counterpart in CQ. And cronet_sample_apk has a overly simple proguard config
that keeps anything in base folder with @VisibleForTesting.

Maybe we could eliminate these minor differences in future so that such reverts
will happen less.

[newt (away), 2015-11-10 21:35:53]

On 2015/11/10 20:38:11, Ian Wen wrote:
> Okay Newton helped me find the reason. Like Robert said, there is indeed some
> minor differences between the release bot in CQ and the bot in waterfall.
> 
> Android Release bot in waterfall builds cronet_sample_apk, which is not built
by
> its counterpart in CQ. And cronet_sample_apk has a overly simple proguard
config
> that keeps anything in base folder with @VisibleForTesting.

Note: the problem isn't actually an "overly simple proguard config". The problem
is that cronet_sample_apk doesn't contain any production code that calls
ThreadUtils.postOnUiThreadDelayed(), so that method gets stripped from
cronet_sample_apk; then the cronet_sample_test_apk test APK fails to build
because the method can't be found in the original APK.

This doesn't happen in chrome_public_apk or other proguarded APKs because all
the other proguarded APK target *do* contain production code that calls
ThreadUtils.postOnUiThreadDelayed(), so the method doesn't get stripped out of
those APKs.

In summary, marking postOnUiThreadDelayed with @VisibleForTesting is necessary
when compiling cronet_sample_test_apk, but not when compiling any other APK
target. cronet_sample_test_apk is built on the waterfall but not on the CQ;
that's the real issue here.

[Yaron, 2015-11-11 00:41:27]

On 2015/11/10 21:35:53, newt wrote:
> On 2015/11/10 20:38:11, Ian Wen wrote:
> > Okay Newton helped me find the reason. Like Robert said, there is indeed
some
> > minor differences between the release bot in CQ and the bot in waterfall.
> > 
> > Android Release bot in waterfall builds cronet_sample_apk, which is not
built
> by
> > its counterpart in CQ. And cronet_sample_apk has a overly simple proguard
> config
> > that keeps anything in base folder with @VisibleForTesting.
> 
> Note: the problem isn't actually an "overly simple proguard config". The
problem
> is that cronet_sample_apk doesn't contain any production code that calls
> ThreadUtils.postOnUiThreadDelayed(), so that method gets stripped from
> cronet_sample_apk; then the cronet_sample_test_apk test APK fails to build
> because the method can't be found in the original APK.
> 
> This doesn't happen in chrome_public_apk or other proguarded APKs because all
> the other proguarded APK target *do* contain production code that calls
> ThreadUtils.postOnUiThreadDelayed(), so the method doesn't get stripped out of
> those APKs.
> 
> In summary, marking postOnUiThreadDelayed with @VisibleForTesting is necessary
> when compiling cronet_sample_test_apk, but not when compiling any other APK
> target. cronet_sample_test_apk is built on the waterfall but not on the CQ;
> that's the real issue here.

Thanks for the forensics Newton. Ian, please file a bug for infra team. We
should ensure try bots match main waterfall