Emaultor keeps running on a seuccessful launch, so this automatically returns after 3 seconds if the process hasn't quit (we have to wait for some period to get stderr in the case of a failure).
I can't come up with a better name; anything with Simulator or Device in it will be confused with the existing IOSSimulator/Device classes (which represent the running devices).
This replaces the --prefer-shared-library flag, which falls back to
regular (non-shared-lib) compile if the NDK is not found, with the
--build-shared-library flag, which exits with an error message if the
NDK is not found.
This simplifies the set of allowed code paths through AOT compile,
resulting in better testability and easier-to-follow logic. It also
results in more predictable behaviour for continuous integration and
other scenarios.
Updates the message emitted when a kernel compile is skipped in the
build bundle action. Since we now use fingerprinting to enable
performance of script snapshots, AOT snapshots, and kernel compiles,
this helps a bit with debugging.
Also switches to trace level logging.
This change adds support for armv7, arm64, and universal iOS apps.
This change eliminates iOS target architecture hardcoding (previously
arm64 only) and uses the target architecture(s) specified in Xcode's
ARCHS setting ('Architectures' in Xcode Build Settings).
For universal binaries, set ARCHS to its default value, $(ARCHS_STANDARD).
Note that after changing the architecture in Xcode, developers should
run 'pod install' from the ios subdirectory of their project. A separate
change (that will land before this one) will add support for
automatically detecting project file and Podfile changes and re-running
pod install if necessary.
This change also adds an --ios-arch option to flutter build aot. In iOS
AOT builds (in profile and release mode), this dictates which
architectures are built into App.framework. This flag should generally
be unnecessary to set manually since flutter build aot is typically only
invoked internally by flutter itself.
This will allow external tools that wrap our test harness to share the
code that generates the test bootstrap.
This change exposed an issue whereby the LocalGoldenFileComparator
was being too strict in its URI handling, so this changes relaxes
that constraint as well (and adds associated tests).
If the developer changes their Xcode build settings and their project
has plugins, pod install is required, (e.g. to pick up changes to the
target architecture).
Similarly, manual edits to the Podfile should trigger a pod install.
