NSLocale objectForKey: may return nil for NSLocaleLanguageCode and
NSLocateCountryCode in certain cases.
This adds a defensive nil check for such cases.
Previously, a call to Dart_TimelineGetMicros() before a call to
Dart_Initialize() resulted in a crash. This was fixed in
dart-lang/sdk@7434bcad57.
Related:
* flutter/flutter#4006: SkyShell.app on Mac crashes on startup
* dart-lang/sdk#26486: [dart_tools_api.h] Dart_TimelineGetMicros crashes on Mac if called before Dart_Initialize
Place all iOS code that relies on APIs introduced in iOS versions later
than our base SDK version (iOS 8) behind @available checks. This allows
us to enable the -Wunguarded-availability compiler flag for iOS builds
in the buildroot repo.
This reverts commit 89b6d435205d9bcdf8dde965dd1b0432482407c5.
Apparently the clang toolchain is still hitting issues. Will give this
another go after the next clang toolchain update.
Guard code that deals with iOS safe area insets behind an @available
check.
This cleans up some old TODOs from before out clang toolchain supported
@available.
* Support .packages option in frontend_server, bundle_path in main_mac.
This is needed to be able to run in mode.
* Remove byte store tests
* Remove unused import
* Fix formatting
* Enable flutter test argument passing on win and linux.
* Fix formatting
* This adds rpc call to simply set asset path.
This is needed when doing hot reload to pick up updated assets.
* Move asset_directory fetch for after view_id. Clean up return. Fix formatting.
* Add SetAssetBundlePath methods implementations for mac and ios
* Fix mac mm
* Fix formatting
* Merge and use nullptr
This change ensures that touches are mapped to the Flutter view
co-ordinate system. In the case of a Flutter view that doesn't share the
same origin and orientation as the screen co-ordinate system, touches
were appled in the wrong location. This bug affected Flutter views whose
origin was not the screen origin and Flutter apps running with the
in-call status bar on iPhones other than the iPhone X.
This adds support for scrolling the primary scroll view to the top on
status bar touches, on the iPhone X.
Notes:
1. The iPhone X status bar doesn't change height when in in-call/etc.
mode, and unlike other iPhones, does scroll to top when in in-call mode.
2. No matter which model of iOS device, the top safe area inset doesn't
change when in in-call mode. In in-call mode, the OS reduces the app
view height by 20px off the top, and the double-height 'in-call' status
bar covers this new inset (outside the view) and there continues to be a
20px safe area in the app.
On iOS 11, rather than comparing status bar height to a hardcoded 20px
'standard height' we now compare to the top safe area inset (which is
always the standard status bar height, regardless of device). On iOS
versions prior to iOS 11, we use the previous logic.
Fixesflutter/flutter#13439
Keyboard height is now treated as a view inset, which could be used to
shrink the content area of the app as is done in the Material Scaffold,
rather than padding, which is used to indicate content areas where user
interaction should be avoided.
This allows for us to start migrating framework classes (notably
Scaffold) to use window.viewInsets.bottom to get the keyboard height.
Once framework updates have landed, we will land an engine patch to
expose the iOS bottom safe area inset as padding.
This change is already landed for Android.
Related issue: flutter/flutter#12098
Previously, we failed to clear/update the mark text range on updates
from the framework. This resulted in a crash if the incoming text value
was shorter than the current mark range when iOS attempts to extract the
mark range substring from the text.
Fixesflutter/flutter#12585
Fixesflutter/flutter#13308
Overlooked this case when I previously removed linear blending. MakeS32 creates a surface with a color space attached (triggering the linear blending behavior). MakeN32 creates a legacy surface (no color space), which matches what the other backend bindings do (including the GL surface factory, and the raster cache).
Window.viewInsets is the set of window-relative insets that describe the
area of the window that an application may want to treat as effectively
reducing the size of the content. Typically this is due to system UI
that fully obscures underlying content, such as the keyboard.
This area differs from padding in that padding is the set of insets that
describe the area of the window that may be partially (or fully)
obscured by system UI or physical intrusions into the view area (e.g.
iPhone X sensor housing, status bar, or the iPhone X home indicator
widget).
This patch does not yet enable the iOS bottom edge safe area. Once the
framework has been updated to use viewInsets for bottom-edge occlusions
(today, the keyboard), the bottom safe area will be enabled and
framework patches that depend on it, landed.
When checking whether render buffer size has changed, apply the device
scale factor used to convert points to pixels to ensure we're not
needlessly re-allocating render buffer storage.
Adds trace + debug log to make this easier to detect in future.
Originally introduced in 2d530daeca438ca24562d290616c0aec5ab76b88, but
rolled back in 0a6e415b60581ef7934032df20401da1fae9ea9f to test whether
it was responsible for regressions to
flutter_gallery_ios__transition_perf benchmarks:
* average_frame_build_time_millis
* missed_frame_build_budget_count
Re-landed in d43d35347594c893687dec7402a525d83f57db10, and reverted in
459f722b86415da01386fe41f37bafa842f11ae8 after it appeared to regress
the above two benchmarks. After recent changes to microtask execution
order which fixed https://github.com/flutter/flutter/issues/9998,
re-introducing this fix results in benchmark improvements to the above
two benchmarks in local testing.
This retains gamut correction (adjusting colors for screens with different capabilities), but does all blending and interpolation with sRGB-encoded values. That matches the behavior expected by most users, as well as the behavior of nearly all other systems. It also greatly simplifies the EGL code.
A future Skia change will make this behavior more of a first-class citizen, so some of these implementation details will change again, but the behavior will not. The bulk of this change (elimination of complication from the GL surface code) is permanent - it's just the SkColorSpaceXformCanvas that will be replaced.
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.
