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

commit d3b77826c61da068d51f2204ddd2b83f213f244c
Author: Findit <findit-for-me@appspot.gserviceaccount.com>
Date: Sat Nov 03 16:24:00 2018

Revert "Android: turning on bytecode checker"

This reverts commit 0301a791b80b0456594e0f0e9108e7a3cf316fe9.

Reason for revert:

Findit (https://goo.gl/kROfz5) identified CL at revision 605068 as the
culprit for flakes in the build cycles as shown on:
https://findit-for-me.appspot.com/waterfall/flake/flake-culprit?key=ag9zfmZpbmRpdC1mb3ItbWVyQwsSDEZsYWtlQ3VscHJpdCIxY2hyb21pdW0vMDMwMWE3OTFiODBiMDQ1NjU5NGUwZjBlOTEwOGU3YTNjZjMxNmZlOQw

Sample Failed Build: https://ci.chromium.org/buildbot/chromium.chromiumos/linux-chromeos-dbg/8686

Sample Failed Step: single_process_mash_browser_tests

Sample Flaky Test: LockScreenNoteTakingTest.DataAvailableOnRestart

Original change's description:
> Android: turning on bytecode checker
> 
> This arg was defaulting to false when it should have defaulted to true.
> 
> TBR=turning off bytecode checks for certain dirs
> 
> Bug:  874854 
> Change-Id: I248ccab0ed52079106b07e43a302927bfa4414c8
> Reviewed-on: https://chromium-review.googlesource.com/c/1309973
> Commit-Queue: Sam Maier <smaier@chromium.org>
> Reviewed-by: agrieve <agrieve@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#605068}

Change-Id: I6cbeb762a8de75dde103493010715c5f5ed8074e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  874854 ,  901616 
Reviewed-on: https://chromium-review.googlesource.com/c/1317030
Cr-Commit-Position: refs/heads/master@{#605180}
[modify] https://crrev.com/d3b77826c61da068d51f2204ddd2b83f213f244c/build/config/android/internal_rules.gni
[modify] https://crrev.com/d3b77826c61da068d51f2204ddd2b83f213f244c/components/data_reduction_proxy/core/common/BUILD.gn
[modify] https://crrev.com/d3b77826c61da068d51f2204ddd2b83f213f244c/content/public/android/BUILD.gn
[modify] https://crrev.com/d3b77826c61da068d51f2204ddd2b83f213f244c/third_party/byte_buddy/BUILD.gn

Removing sheriff label since the CL was reverted.

I'm hopeful that https://chromium-review.googlesource.com/c/chromium/src/+/1316438/ will help with this.

I suspect the problem is related to how LockScreenNoteTakingTest runs 2 JS tests simultaneously then has multiple result catchers. The tests seem sensitive to having an additional runloop spin between the two result catchers, which makes me wonder if they happen to pass right now because there's some async event that's *not* happening because the test completes quickly.

If this continues to be a problem I think we should either:
1. Disable the first-run toast in tests, which would simplify windowing behavior
2. Break the tests into parts so only one JS test runs in each GTEST

I'm not sure that cl will help - DataAvailableOnRestart does not use RunTestAppInLockScreenContext (and uses a single ResultCatcher).

Let me take a closer look.

OK. You can run single_process_mash_browser_tests with browser_tests --enable-features=SingleProcessMash

I think something like this should fix it:
https://chromium-review.googlesource.com/c/chromium/src/+/1324870

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

commit a0502088c5fc9dfc91359637617689f22d1d08ce
Author: Toni Barzic <tbarzic@chromium.org>
Date: Thu Nov 08 01:37:41 2018

Fix LockScreenNoteTakingTest.DataAvailableOnRestart

The test has PRE_DataAvailableOnRestart part which creates a note in
lock screen note storage. DataAvailableOnRestart then verifies that a
onDataItemsAvailable event is dispatched as the user session is started.
The event is dispatched early on during the test - before the test body
is run, which means there is no guarantee that a result catcher created
in the test body will be created before the test app runs all the tests,
and thus it might miss a test result message.

To fix the issue, update the LockScreenNoteTakingTest setup to create a
result catcher just after the browser main parts are created - this should
be early enough to catch any messages from the test app (i.e. before the
event observed by the test app is dispatched), but late enough to have
NotificationService available (without it extensions::ResultCatcher
cannot be created).

BUG= 901616 

Change-Id: I58b3ccda9b93bc355bab7fb1f24e2d4a769c44d8
Reviewed-on: https://chromium-review.googlesource.com/c/1324870
Commit-Queue: Toni Baržić <tbarzic@chromium.org>
Reviewed-by: James Cook <jamescook@chromium.org>
Cr-Commit-Position: refs/heads/master@{#606277}
[modify] https://crrev.com/a0502088c5fc9dfc91359637617689f22d1d08ce/chrome/browser/chromeos/lock_screen_apps/note_taking_browsertest.cc

Flake dashboard seems happier since that CL landed. Thanks for fixing it!