With the update to HEAD of the Fuchsia buildtools repo, the new clang
toolchain picked up caused link-time breakage in android x86_64
libFlutter.so builds.
Sample log:
https://build.chromium.org/p/client.flutter/builders/Linux%20Engine/builds/1974/steps/build%20android_debug_x64/logs/stdio
Sample failure:
FAILED: libflutter.so libflutter.so.TOC lib.stripped/libflutter.so
../../third_party/android_tools/ndk/toolchains/x86_64-4.9/prebuilt/linux-x86_64/lib/gcc/x86_64-linux-android/4.9.x/../../../../x86_64-linux-android/bin/ld.gold: error: obj/flutter/shell/platform/android/libflutter/android_context_gl.o: unsupported reloc 42 against global symbol std::__ndk1::num_put<char, std::__ndk1::ostreambuf_iterator<char, std::__ndk1::char_traits<char> > >::id
This reverts commit 8ad42f0dae3cb1267c2b9ab99db80e4696ddbc3d.
* Roll Fuchsia buildtools to 85907c59e97527d79bbfdfd849d8e85c24959cc5
This also updates Flutter buildroot to a6e52dbb776c45cc8c57d7143b8eb8b2e762fdfb
which disables -Wtautological-constant-compare temporarily until
https://reviews.llvm.org/D39462 lands in clang. This is in line with
Fuchsia's compiler options.
* Apply clang-format diffs
No logical changes. This applies clang-format from the latest Fuchsia
buildtools to the engine codebase.
There are two different sets of view insets that applications may want
to track in order to avoid unwanted interaction with system UI:
1. OS UI that effectively shrinks the Flutter view from a UX point of
view: e.g., when the keyboard opens, it occludes the bottom of the
screen and the view should be adjusted such that the bottom, for the
purposes of scrolling is just above the keyboard.
2. OS UI that is overlaid over the application, but into which the
application should draw. e.g., the Home indicator on the iPhone X
typically appears near the bottom of the screen, overlaid over app
content. Content should be rendered within this 'safe area' but apps
should avoid requiring user interaction there. For example, list
views may want to include some small amount of additional padding to
ensure the last list item can scroll above this area.
Since Flutter does not currently distinguish between these two cases,
this patch disables the bottom safe area inset until API is added to
support these separately.
This change exposes the view safe area insets (introduced in iOS 11) to
the framework via MediaQuery.of(context).padding. Safe area insets are
the view insets (padding) inside of which content can be relied on to
display without truncation/clipping, as would occur with e.g. the iPhone
X sensor notch.
As this API was added in iOS 11, we place it behind a runtime guard
checking OS level.
Until the runtime support for @avialable lands in the next Fuchsia
buildtools rev, ignore -Wunguarded-availability-new around the safe area
insets check and use an FML runtime check instead.
* Revert "Pass option to reuse an existing runtime controller (#4253)"
This reverts commit 57f361dc6abcd8441c444882c5e8bb99519532f3.
* Revert "Document the Porter-Duff operators. (#4250)"
This reverts commit b15fa9c64e1028187ec9592289919d77a6843802.
* Revert "Move channel and codec related files to common (#4225)"
This reverts commit 674a3f5869d3ae0e7ea3583a2d0942e184817903.
* Don't crash if there is only a single SemanticsNode
Previously, the code assumed that the root SemanticsNode will allways have a child. This is not true as can be seen in the hello_world example app, which would crash when a11y is turned on.
* review comment
By adding these events the new developer centric timeline will be able
to identify and correlate events related to the different stages of the
drawing pipeline.
Roll Dart to 62045a4590a333ae557f8f261a909ee75449cd70
* Fix remaining ftl->fxl conversions
The previous scripting pass at this did not account for objective c file endings
* Update tonic DEPS reference to the post-fxl version
- Assumes only the Dart VM is interested in idle notification.
- Gives the VM the time remaining in each frame.
- Gives the VM 100ms if there is no pending frame.
Issue flutter/flutter#9594
For consistency with Android, when the engine receives a
TextInput.setEditingState message from the framework, and the text has
changed, we now send a TextInputClient.updateEditingState message back
to the framework with the updated state from the engine. The framework
currently relies on this behaviour to trigger onChanged events in
certain scenarios (e.g., on tapping Paste in the selection controls).
Note: it may be more desirable for the framework to trigger the
onChanged calls without relying on the return message from the engine,
but this change ensures consistent behaviour across iOS and Android
until we've evaluated the pros/cons of such an approach.
* Add back launch screen view until first frame on iOS
* improvements
* Move callback plumbing from ios surfaces to the gpu rasterizer. Didn’t wire java JNI yet.
* Android JNI
* Fix ios reference count and let android engine manage a view on top with launch screen
* Hook up Android activity and view
* review notes
* review notes
* Move thread switching upstream. Use weak references for callbacks.
* Some clean up
