Matan Lurey 9e273d5e6e
Remove scenario_app/android and rename to ios_scenario_app. (#160992)
🚫 **BLOCKED** : Do not merge until
https://github.com/flutter/flutter/issues/161261 (additional test
coverage).

---

This PR eliminates (1) `scenario_app/android`, and all references to an
Android `scenario_app`, including documentation, CI configuration, build
rules, test runner, Android-side test application, and (2), to verify
and disambiguate the remains, renames the folder `ios_scenario_app`,
which is now accurate.

It also eliminates elements that were _only_ used in the Android-side
scenario_app, such as Firebase Test Lab uploading.

I would be open to doing this in phases if we thought it was better to
do so, but given its mostly a mechanical change (and by renaming the
directory, references can be checked merely by looking for
`/\bscenario_app/`, I believe this is safe to iterate on and eventually
merge after the holidays.

## Background

As of the merged mono-repo, there is no longer a requirement for the
engine to be testable as a standalone unit.

As an example,
[`%ENGINE%/testing/scenario_app`](3762f2e973/engine/src/flutter/testing/scenario_app),
which was intended to _emulate_ the Flutter framework (and some of
`flutter_tools` tooling), load the iOS and Android embedder, and run
various "scenarios" (which ran a combination of `dart:ui` code and
Android Java/iOS Obj-C) verifying golden-file screenshots.

Instead, it is now possible to write and run _real_ (full) Flutter apps
the same way that an end-user (or our own tests) would. One such example
is
[`dev/native_driver_test`](https://github.com/flutter/flutter/tree/master/dev/integration_tests/native_driver_test),
which is a full-fledged Flutter app, which uses standard tooling (i.e.
`flutter`), to test most of the same elements that previously were only
tested in the Android version of `scenario_app`.
2025-01-28 03:43:46 +00:00
..
.gn

OpenSSF Scorecard

buildroot

Build environment for the Flutter engine

This repository is used by the flutter/engine repository. For instructions on how to use it, see that repository's CONTRIBUTING.md file.

To update your checkout to use the latest buildroot, run gclient sync.

To submit patches to this buildroot repository, create a branch, push to that branch, then submit a PR on GitHub for that branch.

To point the engine to a new version of buildroot after your patch is merged, update the buildroot hash in the engine's DEPS file.