design doc in progress here: https://docs.google.com/a/chromium.org/document/d/1ktjk-lMK59SAwKT86QoRTlduvZ8QKdIJzRcIHQZRL8w/edit?usp=sharing

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/05f3312145a23913441d0e1a0f228fd349ae8f9f

commit 05f3312145a23913441d0e1a0f228fd349ae8f9f
Author: jbudorick <jbudorick@chromium.org>
Date: Thu Jul 07 18:11:00 2016

[Android] Create buildable browser_tests gn target for android.

The target currently contains no tests, but it builds and can successfully
report itself as empty w/ --gtest_list_tests.

This should be a no-op for non-Android platforms.

BUG=611756

Review-Url: https://codereview.chromium.org/2106193002
Cr-Commit-Position: refs/heads/master@{#404179}

[modify] https://crrev.com/05f3312145a23913441d0e1a0f228fd349ae8f9f/chrome/chrome_tests.gypi
[modify] https://crrev.com/05f3312145a23913441d0e1a0f228fd349ae8f9f/chrome/test/BUILD.gn

starting to work on a doc for changes related to InProcessBrowserTest / Browser here: https://docs.google.com/a/chromium.org/document/d/1pmnl2tc9mmBdgA9l-jie-Appy7ENXWV7dnfHL3NapbM/edit?usp=sharing

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d5db1ef9a94f0d7e58118c9ff4822df7b6f56317

commit d5db1ef9a94f0d7e58118c9ff4822df7b6f56317
Author: thakis <thakis@chromium.org>
Date: Wed Nov 02 18:00:28 2016

Don't run blink_platform_unittests, browser_tests on x64 Android bot.

They don't pass on Android yet.

BUG=661623,611756, 584508 , 590888 

Review-Url: https://codereview.chromium.org/2473463003
Cr-Commit-Position: refs/heads/master@{#429337}

[modify] https://crrev.com/d5db1ef9a94f0d7e58118c9ff4822df7b6f56317/testing/buildbot/chromium.fyi.json

OOC, what's the current status/plan on this effort?

Didn't make progress last quarter. Trying to finish https://bugs.chromium.org/p/chromium/issues/detail?id=567947 and then will get back to it.

(reverting to assigned since I'm not working on it at the moment, will set back to started when I get back to it)

Hi John,

I know you planned to work on the https://crbug.com/567947 before continuing with this and seems like this issue is also blocked on the https://crbug.com/654704, but you would help me a lot if you could share your expectations on when this might be done.

Thanks in advance.

thekondr: no current expectations on this one at the moment, unfortunately. You're correct about the ordering re 567947, and I'm going to try to get to that one before the end of the year.

Can anyone list the blocking issues why we can't run the browser_tests on Android? Thanks

As discussed on the email thread: the primary one is that InProcessBrowserTest (https://codesearch.chromium.org/chromium/src/chrome/test/base/in_process_browser_test.h) is heavily reliant on Browser (https://codesearch.chromium.org/chromium/src/chrome/browser/ui/browser.h) which isn't used on Android.

Thanks John. 

Sorry for naive questions.  Why this test is depended on the component not supported on Android.  Is that because the test is also required for desktop? 
If so, I'd think
1. remove dependency from tests for Android
2. create a dummy component on Android for this test.

It seems #1 requires heavy efforts of re-writing the tests.  

My understanding is that InProcessBrowserTest predates the existence of the Android version of chromium -- the framework was written while all builds of chromium used Browser. The dependency in this case is core to the framework -- bringing up a Browser is why it exists: https://codesearch.chromium.org/chromium/src/chrome/test/base/in_process_browser_test.h?q=in_process_browser_test&sq=package:chromium&g=0&l=55

... so I don't think removing it is an option. I got partway through outlining my proposal for handling Browser in the doc linked in #3. I wouldn't be surprised if the specifics have bitrotten, but I still suspect that introducing an adapter layer above Browser will be involved.

John's right - android port is different and can't bring in browser because it pulls in too many desktop dependencies and would bloat. the adapter layer seems like the easiest approach

I like this option as well, though, I'd ask any performance impact with the adapter layer.

#19: you might be thinking about an adapter in a different sense; perhaps we can discuss it more next week?