If the mapping callback is not set or it the callback returns invalid data, ICU initialization will be embedder responsibility.
This affects all embedders and the following have been audited:
* Android: Via a symbol mapping.
* iOS: Via a file mapping.
* Embedder: Via a file mapping.
* Fuchsia: Via a VMO mapping
* Test shells and Flutter tester: Via file mapping with ICU data needing to be next to the executable.
The GetMapping calls removed in this patch had the same code and had to be repeated across different test harnesses as well as in dart_snapshot.cc. Just make this a factory method so the code is less verbose.
This reverts commit 0fcfa0df2aa19947ad73882ab4fb24fc9124e47b.
Windows depends on referencing the snapshot symbols directly instead of
via dlsym. Something in the way these symbolsa are generated in
bin_to_assembly.py is causing them to be inaccessible at runtime.
When flutter/synchronization was first authored, we did not own fml (it was called fxl then). Now we do, so use a single spot for such utilities. The pipeline was meant to be a general purpose utility that was only ever used by the animator (it even has animator specific tracing), so move that to shell instead (where the animator resides).
Currently, all Flutter threads are managed by the engine itself. This works for
all threads except the platform thread. On this thread, the engine cannot see
the underlying event multiplexing mechanism. Using the new task runner
interfaces, the engine can relinquish the task of setting up the event
multiplexing mechanism and instead have the embedder provide one for it during
setup.
This scheme is only wired up for the platform thread. But, the eventual goal
is to expose this message loop interoperability for all threads.
This will allow us to easily visualize the time the platform informed the engine of a vsync event, its arguments, and when the engine began its UI thread workload using this information.
Verified that the tests fail on issues like https://github.com/flutter/engine/pull/8166. Unfortunately, there is no x-platform way to perform this check but this should gate incorrect traces being added to the engine.
Prior to this the Android embedder code would extract the icudtl.dat asset out
of the APK and write it to local disk during the first startup of the app.
This change will make that work unnecessary and eliminate the risk of ICU
failures due to errors in the extraction process.
libtrace-provider has libtrace listed as a dependency when really it
does not have any such dependency. This lets trace clients use
libtrace-provider as a dependency when what they really mean is libtrace.
This errant dependency in trace-provider is being fixed, which
means we need to fix these clients.
* Revert "Revert "Guard the service protocol's global handlers list with a reader/writer lock (#6888) #6895" (#6899)"
This reverts commit b6e93759faa92a96650e326b0e82578a6803c46d and applies fix for tests on Windows.
* Reland guard the service protocol's global handlers list with a reader/writer lock.
* Remove blank line
The service protocol holds the lock while waiting for completion of service
RPC tasks. These tasks (specifically hot restart/RunInView) may need to
modify a handler's description data.
Task execution and ServiceProtocol::SetHandlerDescription will obtain a shared
lock to make this possible. AddHandler and RemoveHandler will obtain an
exclusive lock in order to guard against a handler being deleted while a
service task is running.
The service protocol holds the lock while waiting for completion of service
RPC tasks. These tasks (specifically hot restart/RunInView) may need to
modify a handler's description data.
Task execution and ServiceProtocol::SetHandlerDescription will obtain a shared
lock to make this possible. AddHandler and RemoveHandler will obtain an
exclusive lock in order to guard against a handler being deleted while a
service task is running.
