[fuchsia] fix and re-enable SessionConnection unittests
This change waits until Scenic is initialized before beginning the test
logic. This should fix the issue where the test starts running before or
during Scenic startup.
On Fuchsia, we can now get executable VMOs from trusted backing
filesystems. This allows us to remove the use of replace_as_executable
in favor of opening files with `fdio_open_fd_at` with the
`OPEN_RIGHT_EXECUTABLE` flag and getting VMOs by calling
`fdio_get_vmo_exec`.
By moving the responsibility for executability into the filesystem, we
are able to remove `deprecated-ambient-replace-as-executable` from
component manifests for non-JIT runners (the JIT runners still call
replace_as_executable in Dart's allocator). It wasn't abundantly clear
whether .cmx files for tests were used purely in AOT runtime
environments or also saw JIT usage, so I left those as-is.
For context: this is a second attempt at #16690, which was reverted
because it broke the Dart JIT runner. The primary difference is that
this time around, we correctly handle absolute vs relative paths,
depending on whether library loading bottoms out in `fdio_open_fd` or
`fdio_open_fd_at`. I've added additional assertions to help ensure any
new usages use the correct shape of path.
Testing: I verified locally that the flutter product runner works on
Astro, and also successfully ran the Dart JIT example test (which was
the thing blocking the google3 roll with the previous attempt at this
patchset).
Co-authored-by: Drew Fisher <zarvox@google.com>
On Fuchsia, we can now get executable VMOs from trusted backing
filesystems. This allows us to remove the use of replace_as_executable
in favor of opening files with `fdio_open_fd_at` with the
`OPEN_RIGHT_EXECUTABLE` flag and getting VMOs by calling
`fdio_get_vmo_exec`.
By moving the responsibility for executability into the filesystem, we
should be able to remove deprecated-ambient-replace-as-executable from
component manifests for non-JIT runners (the JIT runners still call
replace_as_executable in Dart's allocator).
Test: verified locally that this works on Astro on a _user build with
the runtime allowlist tightened.
No change in behavior expected. We have 2 frames in flight as before. By switching to Present2 and specifying a kMaxFramesInFlight however, we allow us greater flexibility to change how Flutter schedules its frames.
This change also adds tests for SessionConnection and VsyncRecorder.
The timezone data in Fuchsia is at a fixed path. This will have the
flutter runner attempt to load it and log, but not fail if loading
does not work out.
Added two tests
(1) Shows that the specific TZ data version loaded takes effect after
initialization
(2) Shows that when TZ data files are absent the initialization
continues.
* Revert "Add flow test fixtures and tests (#13986)"
This reverts commit 620f5281b819f304e8e9e945222e26b17b087cc3.
* Revert "Dynamically determine whether to use offscreen surface based on need (#13976)"
This reverts commit a86ef946563b020108320bbfb974bf7343284fd3.
This reverts commit 6c763bb551cbc06da59b6a55b4c5ee0eccb6575f.
The reverted code was not the root cause of the issues with rolling
flutter into fuchsia, so adding it back.
In addition, lowering the severity of the connection error at the outset
to WARNING; since it is not a hard failure.
The intention of the property provider is to try to connect, not
bail out if connection is not possible.
This code tried to connect unconditionally, which is not what we wanted.
Removing this initialization code to enable a roll, and will fix in a
followup.
This resolves the following error on Fuchsia: Component fuchsia-pkg://fuchsia.com/flutter_aot_product_runner#meta/flutter_aot_product_runner.cmx is not allowed to connect to fuchsia.intl.PropertyProvider because this service is not present in the component's sandbox.
The FIDL service `fuchsia.intl.PropertyProvider` is a service that
the flutter runner can use to obtain information on system preferred
locales.
This change sends a platform message "setLocale" on the channel
"flutter/localization", based on the values provided by the above
mentioned FIDL service.
Credit: most of this was initially written by @kpozin; I ported it
to out-of-tree flutter engine.
Tested:
1. Compile and publish the unit tests package as shown in
the script below.
2. In a Fuchsia repository (pointed to by `$FUCHSIA_DIR`), run
`fx serve`
3. `fx shell run fuchsia-pkg://fuchsia.com/flutter_runner_tests#meta/flutter_runner_tests.cmx`
The script used to update the unit tests.
```bash
set -x
FLUTTER_ENGINE_DIR="${FLUTTER_ENGINE_DIR:-$HOME/fx/flutter/engine/src}"
readonly OUT_DIR="${FLUTTER_ENGINE_DIR}/out"
(
cd ${FLUTTER_ENGINE_DIR}
./flutter/tools/gn --fuchsia --fuchsia-cpu x64 --unoptimized
ninja -j 100 -C "${OUT_DIR}/fuchsia_debug_unopt_x64"
cp "${OUT_DIR}/compile_commands.json" "${FLUTTER_ENGINE_DIR}"
echo "Publishing the tests package"
"${FLUTTER_ENGINE_DIR}/fuchsia/sdk/linux/tools/pm" publish \
-a -r $FUCHSIA_DIR/out/release/amber-files \
-f "${FLUTTER_ENGINE_DIR}/out/fuchsia_debug_unopt_x64/flutter_runner_tests-0.far"
)
```
* [fidl][flutter_runner] Port Migrate to new fit::optional compatible APIs
Updated all call-sites.
See: https://fuchsia-review.googlesource.com/c/fuchsia/+/304389
FIDL-564 #comment
Change-Id: I831712ffd4a47b8fc9cf1fe237b709a1b983109f
* fix observatory port and re-sync cmx files
Use fdio_ns_connect to connect to services in a namespace. For pure
persistant fidl services the old path of creating a file descriptor and
then opening a channel to that file descriptor doesn't work.
We should provide a way to directly connect to a service without first
treating it as a file.
Test:
* workstation.frank, reboot button on main menu works.
* astro, device_settings "erase user data" reboot works.
Change-Id: I725ba9350547309bebb5530aa44236f841d88f99
... being renamed from fuchsia.tracelink.Register.
fuchsia.tracelink.Registry will be removed after change lands in fuchsia.
PT-127
Change-Id: Ie876228cf9d1e6fb052877e65b47918fdd0b9696
Ported from Topaz tree.
Bug: SEC-314
dding this feature all fuchsia components as a pre-flight step
as we restrict the ability for arbitrary processes to make
VMOs executable.
