Note that the situation is a little bit more complicated than that. I.e. for regular APKs the following happens:

- For debug builds, Foo.apk is built, as well as FooTest.apk which contains
  all the instrumentation tests for Foo. At runtime FooTest.apk is run and
  will load Fool.apk on demand and use reflection or whatever to access
  the Foo.apk methods and call them.

- For release builds, a special FooForTest.apk is built which contains the
  code for both Foo.apk and FooTest.apk in a single package. This is done due
  to proguarding, which prevent the debug scheme from working correctly
  (among other things).

When switching to bundles, the plan would be:

- For debug builds, generate the bundle Foo.aab, then installable .apks archive
  Foo.apks from it, as well as FooTest.apk (this one doesn't need to be a
  bundle).

  Note that installing .apks on the device should be supported by our
  instrumentation test runner scripts as well.

- For release builds, generate a single bundle FooForTest.aab, then its
  installable FooForTest.apks archive, which is what will run during
  testing.

Adding a comment here to say that for testing official release builds, the .aab -> .apks generation step may involve a round trip with the Play Store, and maybe even a trip to the Android signing server (if the .apk is intended to be installed on an Android system image).

Slight correction for #1 above, the FooTest.apk code is loaded into Foo.apk's process at load time, not the opposite. For more details see:

https://chromium.googlesource.com/chromium/src/+/master/testing/android/docs/components_for_testing.md

Increasing priority since this bug is blocking bundle release.

Spoke to tiborg@ offline, and this probably doesn't need to block bundle release since we already use a different apk specific for tests (ChromePublicForTest). 

digit@, I've been looking at getting rid of apk_under_test in issue 890452 - do you still think it makes sense to switch our instrumentation tests to use bundles?

To answer #6, Not necessarily. In all cases I agree that this should not block bundle releases anymore. Thanks!

Decreasing priority again since this is not blocking the bundle release.