This allows Fuchsia components executed by the Flutter runner to
specify a directory containing assets if they wish to store assets
separate from program data. This is specified in the program metadata
field within the component's specification with the new "assets"
attribute. If this attribute is absent, assets are loaded relative to
the path specified in the "data" attribute as before.
This is useful in the short term to use a location in the package where
we can store small files more efficiently. It is also potentially
useful longer term to enforce a stronger separatation between
executable program data and non-executable assets.
This commit adds some basic unit testing for the data parsing to the
flutter_runner_tests suite.
In order to better support different products on Fuchsia, we should
change performance-sensitive attributes based on config files passed in.
This change does so for `vsync_offset`.
Build rules still reference creating share snapshot data and instructions. This makes the engine to always pass them as empty to the dart vm. To be followed up with a change to alter the build rules to stop referencing the shared snapshots.
This is not being used currently and the fact that the runner will be built outside of the flutter tree means that the apps will not have much to gain via shared snapshots. The rationale behind this change is to partially make migrating the runner out of topaz tree easier.
Change-Id: Ibc4dd6a298d65082416af753522f5a17c88a750a
This re-enables unhandled Dart error handling in Flutter applications,
which was removed in a76b958.
The error handling as originally landed was unsafe. Specifically, in the
case where the unhandled error handler was triggered during shutdown,
there was a race condition which could cause a crash in the following
scenario:
1. Runner::OnApplicationTerminate() is triggered, which posts a task to
the application's platform thread will free the Application instance
and terminate the platform thread.
2. Before that task is serviced, the unhandled error handler is called
(by hooks.dart -> window.cc -> ui_dart_state.cc) on the UI thread.
3. The kill task is serviced and the Application dtor and Thread::Quit()
are called, terminating the platform thread.
4. The unhandled error handler attempts to post a task to the platform
thread, whose thread was killed in step 3. This triggers a crash.
Fixing this requires a mechanism for the message loop to know that the
associated thread has been terminated out from under it.
This patch adds mitigation for this scenario, but remains
non-threadsafe/racy. We pass the unhandled error handler a weak pointer
to the Application and check it before posting a task to the platform
thread. This has two issues:
1. WeakPtr isn't threadsafe, and assumes that all operations occur on a
single thread. We're checking its value (which is mutated on the
platform thread) on the UI thread without synchronization.
2. Even with a guarantee that the WeakPtr state were synchronized,
there's a window between when we check the weak pointer and when we
post to the platform thread in which application shutdown and thread
destruction may occur.
This unsafe mitigation is being landed in order to unblock a high
priority bug (FL-256) on a short schedule, and a proper refactoring will
be required to make this properly threadsafe.
Change-Id: If60d1d3ca5799d82597f8a3acc4ddd3871058972
Ported from Topaz tree.
