stuartmorgan-g

Closing as out of scope; the OS killing an app in this scenario is not something we have any control over (and as discussed above, restoration is up to app...

> The tests are cirrus so this will have no effect immediately. 🤦🏻 Sorry, I spaced on that when I sent you that trial PR. We can try spinning up...

It's a new feature. I have a test that would be perfect for this, which is the custom package test, but it's still on Cirrus because there hasn't been much...

@ricardoamador I've hacked up a test PR that should work for testing emulator recipe support: https://github.com/flutter/packages/pull/4377 I've replaced the script run by `Linux dart_unit_test_shard_1 master` and `Linux dart_unit_test_shard_2 master` to...

> I've replaced the script run by `Linux dart_unit_test_shard_1 master` and `Linux dart_unit_test_shard_2 master` to instead `flutter drive` Android tests. It's currently showing `No Android devices available` as expected; with...

flutter/packages uses a generic recipe so that almost all CI changes can be made in-repo, instead of the cumbersome process of having to change another repo (where we don't get...

I don't know how much difference the machine configuration makes in practice; we could do some tests and see how reasonable it is, and how much we need to adjust...

I was able to successfully set up a different emulator-based test (https://github.com/flutter/packages/pull/4484) so it's looking good! Next week I'll investigate the hang in the primary Android integration tests.

None of the problems were infra-related, they are all test-specific. Given that, we can close this as done. Thanks again for getting this set up!

@reidbaker This was auto-assigned to be because I forgot to update flutter/flutter test ownership after Android handoff. I'll send a PR for updating the test ownership later today, but this...