Right now it's pretty awkward to use a single example app for both E2E and Espresso tests running on the plugins CI.

gradle app:assembleDebug will try to include all the tests by default, pointing at a single Dart entry point file.

The E2E package's FlutterRunner expects the E2EWidgetsFlutterBinding while Espresso expects the Flutter driver extension's _DriverBinding.

Possible high-level approaches:

1. Have multiple example apps, one for each type of test. This isn't very satisfying since an app developer probably wants to share the majority of their code in a single Android app project. One app could depend on the other, allowing to some code reuse. In the future, developers will want to run and debugging a single test, so it would be nice if our approach scales to that.
2. Use test filtering to omit some tests from the app bundle. CI could point at a different test file depending on the type of test being run. This is a bit less efficient as you have to make an app bundle for each test you want to run, and it could be somewhat brittle.
3. Combine E2EWidgetsFlutterBinding and _DriverBinding into a binding class that is compatible with the flutter_test package and can also receive commands from EspressoFlutter, FlutterDriver, etc. This is probably the right long term approach but it will require some refactoring of the class hierarchy.
4. @xster suggested passing arguments to the Flutter shell when it is created. https://github.com/flutter/engine/blob/master/shell/platform/android/io/flutter/embedding/engine/FlutterShellArgs.java
5. Multiple entry points, using getDartEntrypointFunctionName.

Related issues

#39842 - Connectivity
#48439 - Android Alarm Manager