[Android] Add support for command-line flags via annotation.

[Android] Add support for command-line flags via annotation.

BUG=433539
Committed: https://crrev.com/d19a57db9b237b197c5910f39ccbf53538ccf92d
Cr-Commit-Position: refs/heads/master@{#314247}

[jbudorick, 2015-01-27 18:15:12]

jbudorick@chromium.org changed reviewers:
+ klundberg@chromium.org, nyquist@chromium.org, tedchoc@chromium.org

[jbudorick, 2015-01-27 18:15:12]

nyquist: base/ (and chrome/, if you want)
tedchoc: content/ and chrome/
klundberg: build/android/

Note that this does not address running a test multiple times with different
sets of command-line flags. That scenario is a bit trickier; I'll try to address
it in a later CL.

[klundberg, 2015-01-27 18:19:12]

LGTM for build/android/

[nyquist, 2015-01-28 23:10:37]

Mostly just nits.

https://codereview.chromium.org/879993002/diff/60001/base/android/java/src/or...
File base/android/java/src/org/chromium/base/BaseChromiumApplication.java
(right):

https://codereview.chromium.org/879993002/diff/60001/base/android/java/src/or...
base/android/java/src/org/chromium/base/BaseChromiumApplication.java:101: public
void initCommandLine() {
Nit: Just put {} on the same line. I believe 'git cl format' does that nowadays.

https://codereview.chromium.org/879993002/diff/60001/base/android/java/src/or...
base/android/java/src/org/chromium/base/BaseChromiumApplication.java:106: *
BaseChromiumApplication.
Nit: {@link BaseChromiumApplication}

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
File
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java
(right):

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java:27:
private static final String TAG = "BaseActivityInstrumentationTestCase";
Nit: I don't think this field is used.

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java:41:
* This will add the difference of the sets of flags specified by
@CommandLineFlags.Add and
Nit: How about using {@link CommandLineFlags.Add} and similarly for Remove?

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java:68:
while (flagIter.hasNext()) {
Nit: I often find it easier to read:
for (String flag : flags) {
  ...

This would also remove the necessity of importing java.util.Iterator.

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java:73:
private Set<String> getClassFlags(Class<?> testClass) {
Nit: This method should be static to signal that it does not access any instance
members.

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java:75:
Set<String> flags = null;
Nit: You are always initializing this field below, so you don't need to
initialize it to null first.

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java:76:
if (superclass != null) {
Optional nit: My personal preference is to not flip null-checks like this when
you have both if and else. I find it easier to read if a then do X else do Y.
I'm fine either way though.

You could also just do:
Set<String> flags = superclass == null ? new HashSet<String>() :
getClassFlags(superclass);

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
File
base/test/android/javatests/src/org/chromium/base/test/util/CommandLineFlags.java
(right):

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/util/CommandLineFlags.java:18:
public class CommandLineFlags {
Nit: Since this class should never be instantiated (and correctly has a private
constructor), please mark it as final so it is easy for new readers to
understand the intent.

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/util/CommandLineFlags.java:21:
* Adds command-line flags to the CommandLine for this test.
Nit: Either use {@link org.chromium.base.CommandLine} here and below, or change
both places to "{Adds/Removes} command-line flags for this test."

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/util/CommandLineFlags.java:26:
public static @interface Add {
Nit: |static| is redundant for inner interfaces here and below.

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/util/CommandLineFlags.java:27:
public String[] value();
Nit: |public| is redundant for interface methods here and below.

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/util/CommandLineFlags.java:33:
* Note that this can only remove flags added via @Add above.
Nit: {@link Add}

https://codereview.chromium.org/879993002/diff/60001/chrome/chrome_shell_test...
File chrome/chrome_shell_test_apk.isolate (right):

https://codereview.chromium.org/879993002/diff/60001/chrome/chrome_shell_test...
chrome/chrome_shell_test_apk.isolate:10:
'<(DEPTH)/chrome/test/data/android/cookie.html',
Are the changes in this file related to this CL?

[Ted C, 2015-01-29 00:39:52]

https://codereview.chromium.org/879993002/diff/60001/base/android/java/src/or...
File base/android/java/src/org/chromium/base/BaseChromiumApplication.java
(right):

https://codereview.chromium.org/879993002/diff/60001/base/android/java/src/or...
base/android/java/src/org/chromium/base/BaseChromiumApplication.java:101: public
void initCommandLine() {
add javadoc

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
File
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java
(right):

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java:42:
* @CommandLineFlags.Remove to the CommandLine. Note that trying to remove a flag
set
This caveat scares me.  If a test is explicitly trying to remove a flag and it
exists in the command line flag file, it will break in an odd and hard to debug
way.

Maybe when removing flags, we should check whether it exists in the CommandLine
already and fail the test if that ever happens.

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java:50:
BaseChromiumApplication.initCommandLine(getInstrumentation().getTargetContext());
You might want to do what is in CommandLineTestUtils which works around where
the target context is null on older versions of android.

        try {
            Assert.assertTrue(CriteriaHelper.pollForCriteria(new Criteria() {
                @Override
                public boolean isSatisfied() {
                    return instrumentation.getTargetContext() != null
                            &&
instrumentation.getTargetContext().getApplicationContext() != null;
                }
            }));
        } catch (InterruptedException e) {
            Log.i("CommandLineTestUtils", "failed to get a non-null target
application context");
        }

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java:82:
if (testClass.isAnnotationPresent(CommandLineFlags.Add.class)) {
Can this and the if below be abstracted out to a helper function with the same
logic above?

I think Method and Class both extend from AnnotatedElement, so it might make it
shareable.

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
File
base/test/android/javatests/src/org/chromium/base/test/util/CommandLineFlags.java
(right):

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/util/CommandLineFlags.java:18:
public class CommandLineFlags {
On 2015/01/28 23:10:36, nyquist wrote:
> Nit: Since this class should never be instantiated (and correctly has a
private
> constructor), please mark it as final so it is easy for new readers to
> understand the intent.

I'm worried that this file name will cause confusion during grepping...but I
don't know if TestCommandLineFlags is any better.

https://codereview.chromium.org/879993002/diff/60001/chrome/android/shell/jav...
File
chrome/android/shell/javatests/src/org/chromium/chrome/shell/ChromeShellTestBase.java
(right):

https://codereview.chromium.org/879993002/diff/60001/chrome/android/shell/jav...
chrome/android/shell/javatests/src/org/chromium/chrome/shell/ChromeShellTestBase.java:33:
@CommandLineFlags.Add({ContentSwitches.ENABLE_TEST_INTENTS})
if there is only one flag, you should be able to drop the {}'s.

Also, why are we adding this flag here when it didn't seem to exist before?

[jbudorick, 2015-01-29 04:46:46]

https://codereview.chromium.org/879993002/diff/60001/base/android/java/src/or...
File base/android/java/src/org/chromium/base/BaseChromiumApplication.java
(right):

https://codereview.chromium.org/879993002/diff/60001/base/android/java/src/or...
base/android/java/src/org/chromium/base/BaseChromiumApplication.java:101: public
void initCommandLine() {
On 2015/01/28 23:10:36, nyquist wrote:
> Nit: Just put {} on the same line. I believe 'git cl format' does that
nowadays.

Done.

https://codereview.chromium.org/879993002/diff/60001/base/android/java/src/or...
base/android/java/src/org/chromium/base/BaseChromiumApplication.java:101: public
void initCommandLine() {
On 2015/01/29 00:39:51, Ted C wrote:
> add javadoc

Done.

https://codereview.chromium.org/879993002/diff/60001/base/android/java/src/or...
base/android/java/src/org/chromium/base/BaseChromiumApplication.java:106: *
BaseChromiumApplication.
On 2015/01/28 23:10:36, nyquist wrote:
> Nit: {@link BaseChromiumApplication}

Done.

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
File
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java
(right):

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java:27:
private static final String TAG = "BaseActivityInstrumentationTestCase";
On 2015/01/28 23:10:36, nyquist wrote:
> Nit: I don't think this field is used.

Removed.

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java:41:
* This will add the difference of the sets of flags specified by
@CommandLineFlags.Add and
On 2015/01/28 23:10:36, nyquist wrote:
> Nit: How about using {@link CommandLineFlags.Add} and similarly for Remove?

Done.

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java:42:
* @CommandLineFlags.Remove to the CommandLine. Note that trying to remove a flag
set
added {@link org.chromium.base.CommandLine} here

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java:42:
* @CommandLineFlags.Remove to the CommandLine. Note that trying to remove a flag
set
On 2015/01/29 00:39:51, Ted C wrote:
> This caveat scares me.  If a test is explicitly trying to remove a flag and it

Understandably so. Neither base::CommandLine nor org.chromium.base.CommandLine
support removal at the moment, though.

> exists in the command line flag file, it will break in an odd and hard to
debug
> way.
> 
> Maybe when removing flags, we should check whether it exists in the
CommandLine
> already and fail the test if that ever happens.

That sounds reasonable.

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java:50:
BaseChromiumApplication.initCommandLine(getInstrumentation().getTargetContext());
On 2015/01/29 00:39:51, Ted C wrote:
> You might want to do what is in CommandLineTestUtils which works around where
> the target context is null on older versions of android.
> 
>         try {
>             Assert.assertTrue(CriteriaHelper.pollForCriteria(new Criteria() {
>                 @Override
>                 public boolean isSatisfied() {
>                     return instrumentation.getTargetContext() != null
>                             &&
> instrumentation.getTargetContext().getApplicationContext() != null;
>                 }
>             }));
>         } catch (InterruptedException e) {
>             Log.i("CommandLineTestUtils", "failed to get a non-null target
> application context");
>         }

Criteria & CriteriaHelper are in content/. I've replicated the functionality
here for now, though doing so is a bit ugly. Moving them into base/ would
theoretically be possible -- neither depends on anything outside of base/ -- but
given how heavily they're currently used, doing so doesn't seem practical.

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java:68:
while (flagIter.hasNext()) {
On 2015/01/28 23:10:36, nyquist wrote:
> Nit: I often find it easier to read:
> for (String flag : flags) {
>   ...
> 
> This would also remove the necessity of importing java.util.Iterator.

Done.

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java:73:
private Set<String> getClassFlags(Class<?> testClass) {
On 2015/01/28 23:10:36, nyquist wrote:
> Nit: This method should be static to signal that it does not access any
instance
> members.

Done.

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java:75:
Set<String> flags = null;
On 2015/01/28 23:10:36, nyquist wrote:
> Nit: You are always initializing this field below, so you don't need to
> initialize it to null first.

Done.

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java:76:
if (superclass != null) {
On 2015/01/28 23:10:36, nyquist wrote:
> Optional nit: My personal preference is to not flip null-checks like this when
> you have both if and else. I find it easier to read if a then do X else do Y.
> I'm fine either way though.
> 
> You could also just do:
> Set<String> flags = superclass == null ? new HashSet<String>() :
> getClassFlags(superclass);

ternary conditional it is

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java:82:
if (testClass.isAnnotationPresent(CommandLineFlags.Add.class)) {
On 2015/01/29 00:39:51, Ted C wrote:
> Can this and the if below be abstracted out to a helper function with the same
> logic above?
> 
> I think Method and Class both extend from AnnotatedElement, so it might make
it
> shareable.

Done.

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
File
base/test/android/javatests/src/org/chromium/base/test/util/CommandLineFlags.java
(right):

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/util/CommandLineFlags.java:18:
public class CommandLineFlags {
On 2015/01/28 23:10:36, nyquist wrote:
> Nit: Since this class should never be instantiated (and correctly has a
private
> constructor), please mark it as final so it is easy for new readers to
> understand the intent.

Done.

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/util/CommandLineFlags.java:21:
* Adds command-line flags to the CommandLine for this test.
On 2015/01/28 23:10:36, nyquist wrote:
> Nit: Either use {@link org.chromium.base.CommandLine} here and below, or
change
> both places to "{Adds/Removes} command-line flags for this test."

@link added.

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/util/CommandLineFlags.java:26:
public static @interface Add {
On 2015/01/28 23:10:36, nyquist wrote:
> Nit: |static| is redundant for inner interfaces here and below.

removed

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/util/CommandLineFlags.java:27:
public String[] value();
On 2015/01/28 23:10:36, nyquist wrote:
> Nit: |public| is redundant for interface methods here and below.

removed

https://codereview.chromium.org/879993002/diff/60001/base/test/android/javate...
base/test/android/javatests/src/org/chromium/base/test/util/CommandLineFlags.java:33:
* Note that this can only remove flags added via @Add above.
On 2015/01/28 23:10:36, nyquist wrote:
> Nit: {@link Add}

Done.

https://codereview.chromium.org/879993002/diff/60001/chrome/android/shell/jav...
File
chrome/android/shell/javatests/src/org/chromium/chrome/shell/ChromeShellTestBase.java
(right):

https://codereview.chromium.org/879993002/diff/60001/chrome/android/shell/jav...
chrome/android/shell/javatests/src/org/chromium/chrome/shell/ChromeShellTestBase.java:33:
@CommandLineFlags.Add({ContentSwitches.ENABLE_TEST_INTENTS})
On 2015/01/29 00:39:51, Ted C wrote:
> if there is only one flag, you should be able to drop the {}'s.
> 

Done.

> Also, why are we adding this flag here when it didn't seem to exist before?

because it's currently set by the test scripts:
https://cs.corp.google.com/#clankium/src/build/android/pylib/instrumentation/...

https://codereview.chromium.org/879993002/diff/60001/chrome/chrome_shell_test...
File chrome/chrome_shell_test_apk.isolate (right):

https://codereview.chromium.org/879993002/diff/60001/chrome/chrome_shell_test...
chrome/chrome_shell_test_apk.isolate:10:
'<(DEPTH)/chrome/test/data/android/cookie.html',
On 2015/01/28 23:10:36, nyquist wrote:
> Are the changes in this file related to this CL?

No, these should be in an upcoming ChromeShellTest.apk -> isolate CL.

[Ted C, 2015-01-30 19:15:26]

lgtm

https://codereview.chromium.org/879993002/diff/120001/base/test/android/javat...
File
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java
(right):

https://codereview.chromium.org/879993002/diff/120001/base/test/android/javat...
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java:58:
Context targetContext = getInstrumentation().getTargetContext();
I actually think we should move CriteriaHelper to base, but it doesn't
need/shouldn't be part of this change.

https://codereview.chromium.org/879993002/diff/120001/base/test/android/javat...
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java:100:
throw new RuntimeException(
Since we're in a test, I would actually do Assert.fail("...") here myself, but I
think this is fine.

https://codereview.chromium.org/879993002/diff/120001/base/test/android/javat...
File
base/test/android/javatests/src/org/chromium/base/test/util/CommandLineFlags.java
(right):

https://codereview.chromium.org/879993002/diff/120001/base/test/android/javat...
base/test/android/javatests/src/org/chromium/base/test/util/CommandLineFlags.java:18:
public final class CommandLineFlags {
We should probably document how these are processed as well.  Mainly how it will
add/remove flags starting at the ancestor classes first and work down the child
classes one at a time until it reaches the actual test class.  Then it
adds/removes them from the method itself.

It's mainly trying to clarify that if a base class adds or removes a command
line flag, the child classes/method always have the ability to overwrite that.

[nyquist, 2015-01-30 23:32:45]

https://codereview.chromium.org/879993002/diff/120001/base/test/android/javat...
File
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java
(right):

https://codereview.chromium.org/879993002/diff/120001/base/test/android/javat...
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java:58:
Context targetContext = getInstrumentation().getTargetContext();
Could you extract getting the target context out to a separate method which
returns null if it fails / times out? If so, add a short comment saying why on
earth we need this sad while-loop.

https://codereview.chromium.org/879993002/diff/120001/base/test/android/javat...
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java:71:
Log.e(TAG, "Unable to get a non-null target context.");
Would it be OK to just fail here instead?

[jbudorick, 2015-01-31 20:11:58]

https://codereview.chromium.org/879993002/diff/120001/base/test/android/javat...
File
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java
(right):

https://codereview.chromium.org/879993002/diff/120001/base/test/android/javat...
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java:58:
Context targetContext = getInstrumentation().getTargetContext();
On 2015/01/30 23:32:44, nyquist wrote:
> Could you extract getting the target context out to a separate method which
> returns null if it fails / times out? If so, add a short comment saying why on
> earth we need this sad while-loop.

Done

https://codereview.chromium.org/879993002/diff/120001/base/test/android/javat...
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java:58:
Context targetContext = getInstrumentation().getTargetContext();
On 2015/01/30 19:15:25, Ted C wrote:
> I actually think we should move CriteriaHelper to base, but it doesn't
> need/shouldn't be part of this change.

Added a TODO to convert this to CriteriaHelper if that happens

https://codereview.chromium.org/879993002/diff/120001/base/test/android/javat...
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java:71:
Log.e(TAG, "Unable to get a non-null target context.");
On 2015/01/30 23:32:44, nyquist wrote:
> Would it be OK to just fail here instead?

I think so. Switched to assertNotNull("...", targetContext)

https://codereview.chromium.org/879993002/diff/120001/base/test/android/javat...
base/test/android/javatests/src/org/chromium/base/test/BaseActivityInstrumentationTestCase.java:100:
throw new RuntimeException(
On 2015/01/30 19:15:25, Ted C wrote:
> Since we're in a test, I would actually do Assert.fail("...") here myself, but
I
> think this is fine.

Incorporated the above if + switched to assertFalse("...", hasSwitch)

https://codereview.chromium.org/879993002/diff/120001/base/test/android/javat...
File
base/test/android/javatests/src/org/chromium/base/test/util/CommandLineFlags.java
(right):

https://codereview.chromium.org/879993002/diff/120001/base/test/android/javat...
base/test/android/javatests/src/org/chromium/base/test/util/CommandLineFlags.java:18:
public final class CommandLineFlags {
On 2015/01/30 19:15:25, Ted C wrote:
> We should probably document how these are processed as well.  Mainly how it
will
> add/remove flags starting at the ancestor classes first and work down the
child
> classes one at a time until it reaches the actual test class.  Then it
> adds/removes them from the method itself.
> 
> It's mainly trying to clarify that if a base class adds or removes a command
> line flag, the child classes/method always have the ability to overwrite that.

Done.

[nyquist, 2015-02-02 19:00:12]

lgtm

[jbudorick, 2015-02-02 19:58:35]

The CQ bit was checked by jbudorick@chromium.org

[commit-bot: I haz the power, 2015-02-02 20:00:14]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/879993002/180001

[commit-bot: I haz the power, 2015-02-02 20:28:40]

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

[commit-bot: I haz the power, 2015-02-02 20:28:41]

Try jobs failed on following builders:
  android_compile_rel on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_compile...)

[jbudorick, 2015-02-02 21:29:35]

The CQ bit was checked by jbudorick@chromium.org

[commit-bot: I haz the power, 2015-02-02 21:30:47]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/879993002/200001

[commit-bot: I haz the power, 2015-02-03 02:18:28]

Committed patchset #11 (id:200001)

[commit-bot: I haz the power, 2015-02-03 02:19:18]

Patchset 11 (id:??) landed as
https://crrev.com/d19a57db9b237b197c5910f39ccbf53538ccf92d
Cr-Commit-Position: refs/heads/master@{#314247}