Work towards https://github.com/flutter/flutter/issues/134969.
These are all self-contained, so I bundled them all together.
All fixes are generated by `clang-tidy --fix`, and manual search/replace if that wasn't sufficient.
https://github.com/flutter/flutter/issues/134452
This patch parses the speed of all CPU data out of /proc and constructs a table that allows us to request high level CPU affinities: performance, efficiency, and not performance. These affinties are applied where appropriate during Android thread construction.
* Extract WideToUTF16String/UTF16StringToWide to FML
In third_party/accessibility, for string conversion, we use a mix of:
* FML
* third_party/accessibility base string utility functions
* static functions local to the translation unit itself
This moves all conversions between UTF16 and wide strings to FML. Note
that this implementation is only safe on platforms where:
* the size of wchar_t and char16_t are the same
* the encoding of wchar_t and char16_t are both UTF-16
which is the case for Windows, hence why these functions are implemented
in a Windows-specific translation unit (wstring_conversion).
Issue: https://github.com/flutter/flutter/issues/118811
* Migrate UTF16ToWide as well
Merges most (but not all) of the impeller .clang-tidy rules into the
main .clang-tidy config. Merges:
readability-identifier-naming.PrivateMemberSuffix (_)
readability-identifier-naming.EnumConstantPrefix (k)
modernize-use-default-member-init.UseAssignment
Does not merge:
readability-identifier-naming.PublicMethodCase (CamelCase)
readability-identifier-naming.PrivateMethodCase (CamelCase)
These last two are not merged due to the non-trivial number of existing
field accessors that use field_name() methods to directly return
field_name_. While these are permitted by the C++ style guide, we may
want to move to a single, simple rule and name everything in CamelCase.
These can be enabled in a followup patch.
No new tests added, since this change is style-only.
General UTF8/UTF16 string conversion utility functions were recently
added to FML. This migrates calls in the Android JNI utils to the common
implementations.
No additional tests added since we're just dropping one implementation
of UTF8/UTF16 functions and making use of an equivalent set that already
has unit tests of its own. The rest of the Android-related code is
already covered by existing unit tests.
Issue: https://github.com/flutter/flutter/issues/98061
Related PR: https://github.com/flutter/engine/pull/31334
We've implemented UTF-8/UTF-16 string encoding conversions in multiple
places, from FML to //flutter/shell/platform/common, to the individual
embedders. This migrates these conversions to FML and adds tests.
Windows APIs use wchar_t-based strings and as a result, we continue to
keep Windows-specific functions in fml/platform/win/wstring_conversion.h.
We break out string_conversions into its own source set since FML brings
with it some Dart dependencies (e.g. dart_timestamp_provider.cc) that
are unused by some targets such as uwptool.exe in the Windows UWP
embedding.
Issue: https://github.com/flutter/flutter/issues/98061
* Reland "Use the systrace recorder if systracing is enabled at startup, and enable systracing in release mode on Android (#28903)" (#29071)"
This reverts commit a7660964b41f64991369341364a43c93317a4a51.
* More logcat
* more logs
* Remove wait
* Avoid plugin registrar exception
* DEFAULT instead of LAUNCHER
* use am instead of monkey
* Update android_systrace_test.py
* Move task_observers.{cc,h} into fml.
This is a preparatory CL. The next CL will cause task_observers.h to
be included from both shell/platform/fuchsia _and_
fml/platform/fuchsia. I imagine it might be gauche for a single file
to be used from both those directories, but it seems way worse for fml
to depend on shell, rather than the other way around.
* Replace flutter_runner::Thread with fml::Thread.
This CL makes the treading logic in Fuchsia's flutter_runner more
consistent with fml expectations, but it still has quirks. Notably:
- Not all async work get posted to a fml::TaskRunner. Some work done
by Fuchsia libraries gets posted directly to
async_get_default_dispatcher(). This work doesn't trigger the
fml::MessageLoop's task observers. As a result, we continue to have
Fuchsia-specific task observers which fire for all async work,
regardless of which way it was posted.
- There's awkwardness when trying to run Fuchsia code on a specific
fml::TaskRunner if that fuchsia code accepts an
async_dispatcher_t. Since you can no longer get an
async_dispatcher_t for a given thread, you instead must post a
closure to the fml::TaskRunner that calls
async_get_default_dispatcher(), and then calls the fuchsia library
with the default dispatcher.
- Some tests still use task_runner_adapter.h because async::Loop
offers more control in unit tests than fml::MessageLoop does.
- If this successfully lands, there will be some cosmetic follow-up
changes to make, like using ThreadHost instead of an array of
fml::Threads.
* Increase stack size in flutter runner.
The previous change removes our custom 1MiB limit on the stack of
newly created threads, so these threads revert to the Fuchsia
default. google-internal tests were failing (without any particular
error in the logs) after this change, so here we just set the default
stack size to 1MiB.
Co-authored-by: Hunter Freyer <hjfreyer@google.com>
